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ABSTRACT 


Inheritance  is  a  necessary  condition  for  construction  of  an  object-oriented  data  model 
(OODM),  but  it  is  not  sufficient  This  is  because  inheritance  implies  to  only  one  hierarchy. 
The  covoing  construct  meets  this  deficiency  because  covering  maps  an  object  in  one 
hierarchy  to  a  class  of  objects  in  another  hinarchy.  To  date,  covering  has  not  beat 
implemented  into  an  existing  OODM  application. 

This  thesis  implements  the  covering  construct  into  a  functioning  object-oriented 
database  environment  Implementation  was  achieved  through  modification  of  data 
constructs  and  the  creation  of  a  user-defined  relation  linking  two  or  more  hinarchies.  Using 
the  Multi-model  Multi-lingual  Dababase  Supercomputer  (MDBS),  a  sample,  working 
application  is  described  illustrating  real  world  applications. 

The  results  of  this  thesis  show  that  the  covering  property  can  be  inq)lemented  into  an 
existing  OODM  without  sacrificing  the  integrity  of  the  data  model.  The  cross-hierarchical 
mapping  afforded  by  covering  is  a  powerful  construct  that  expands  the  capabilities  of  the 
model  beyond  pure  inheritance.  This  makes  the  OODM  suitable  for  a  far  wider  range  of 
applications.  Together,  inheritance  and  dbvering  meet  the  necessary  and  sufficient 
conditions  of  the  OODM. 
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L  INTRODUCTION 


A.  BACKGROUND 

Since  the  invention  of  the  computer,  the  size  and  complexity  of  software  applications 
have  grown  steadily.  Starting  from  simple  repetitious  mathematical  calculations,  these 
applications  have  grown  to  include  computer-aided  design,  artificial  intelligence,  and  a 
host  of  others.  Perhaps,  the  most  natural  use  for  con^uters  has  been  in  the  storage  and 
manipulation  of  large  databases,  since  databases  represent  information  collections. 
Database  applications  touch  nearly  every  use  of  computers,  because  every  application 
relies  on  some  sets  of  data.  As  computers  became  more  complex,  higher-level  programing 
languages  were  developed  to  allow  software  to  keep  pace  with  the  advances  in  hardware. 
Moreover,  these  high-level  languages  have  also  allowed  programmers  to  implement 
abstract  concepts. 

ParaUeling  the  growth  in  programming  languages  has  been  the  development  of 
specific  database  models  to  handle  increasingly  large  databases  for  database  applications. 
These  include  the  classical  relational,  hierarchical,  and  network  models.  Yet,  when 
programs  became  increasingly  complex,  as  with  the  development  of  computer-aided- 
design  and/or  computer-aided-manufacturing  (CAD/CAM)  applications,  these  classical 
models  fall  short  of  adequately  supporting  the  more  demanding  and  complex  applications. 
There  is  a  need  for  a  more  flexible  and  powerful  model  to  keep  pace  with  the  new  demands. 

The  objea-oriented  approach  to  database  management  is  a  direct  consequence  of  the 
following  two  factors.  One  is  the  rapid  movenMnt  away  from  imperative-programming 
paradigms  and  more  towards  object-oriented-programming  paradigms.  Second  is  the  need 
for  more  flexibility,  power,  and  abstraction  required  for  modelling  sophisticated 
applications. 

Before  discussing  the  Object-Oriented  Data  Model  (OODM)  and  its  constructs,  we 
examine  the  classical  data  models  and  their  intended  usages: 
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The  Relational  Model:  Introduced  by  Codd  in  1970,  this  model  stores  data  in  the  form 
of  tables.  Each  attribute  is  assigned  a  column  of  the  table.  Key  attributes  are  used  to  link 
the  tables  and  provide  a  means  of  accessing  data  from  multiple  tables.  This  makes  the 
relational  model  ideal  for  record-keeping  applications.  For  example,  data  regarding  a 
company’s  employees  may  be  grouped  by  department  Employees  of  each  department  may 
then  be  represented  by  a  table,  with  each  column  of  the  table  corre^nding  to  a  particular 
employee  attribute  such  as  age,  address,  salary  and  others.  Each  row  in  the  table 
corresponds  to  an  individual  employee.  Queries  are  made  using  a  relational  data  language, 
SQL,  which  translates  relational  language  constructs  into  computer  recognizable 
commands. 

The  Hierarchical  Data  Model:  As  its  name  implies,  the  hierarchical  model  has  been 
developed  to  illustrate  the  many  naturally  occurring  hierarchies  found  in  the  world. 
Corporate  structures,  biological  classifications,  and  family  trees  are  logical  examples  of 
these  hierarchies.  The  hierarchial  data  model  uses  a  “parent-child”  relationship  to  describe 
the  one-to-many  characteristic  of  a  tree  structure.  This  parent-child  relationship  is  an  ideal 
modelling  tool  for  data  related  to  product  assemblies.  To  illustrate,  we  can  break  down  a 
product  into  its  component  parts,  which  in  turn,  into  their  sub-component  parts.  Thus,  there 
exists  a  natural  hierarchical  one-to-many  relationship  corresponding  to  every  level  of  the 
assembly. 

The  Network  Data  Model:  The  fundamental  constructs  of  the  network  model  are 
record  types  and  set  types.  Data  are  stored  in  records;  records  of  same  value  types  of  are 
grouped  into  record  types.  The  set  type  describes  the  relationship  between  the  two  record 
types.  Thus,  the  network  model  can  model  one-to-many,  many-to-one,  one-to-one,  and 
many-to-many  relationships.  This  model  is  best  suited  for  inventory  control  applications. 
For  example,  an  auto  parts  supplier  may  have  many  buyers  for  a  specific  part,  and  at  the 
same  time  the  supplier  may  have  many  individual  auto  parts  to  sell.  Conversely,  the  buyer 
may  buy  different  parts  from  one  or  many  different  manufacturers.  Queries  are  written  in  a 
network  language,  COD  AS  YL. 
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These  models  can  be  termed  as  task-specific.  That  is,  they  are  best  suited  for 
particular  tasks,  but  not  flexible  enough  for  the  user  to  easily  apply  them  to  alternative  tasks 
and  their  use.  The  result  is  that  the  database  user  tends  to  use  tiie  model  with  which  he  is 
most  familiar.  Furthermore,  as  difierent  applications  are  needed,  the  database  user  will  tend 
to  adapt  the  model  most  familiar  to  him  rather  than  employ  tiie  model  best  suited  to  tiie  new 

task. 


B.  THE  OBJECT-ORIENTED  DATA  MODEL  (OODM) 

The  object-oriented  data  model  (OODM)  marks  a  significant  departure  fi'om  other 
data  models.  First,  unlike  the  aforementioned  models,  OODM  is  not  based  on  a  standard 
language  such  as  SQL  or  CODASYL.  Rather,  it  uses  conventional  languages  such  as  C, 
C++,  and  Ada,  and  borrows  many  of  its  concepts  fi'om  object-oriented  programing.  In  fact, 
there  are  many  different  object-oriented  data  models,  languages,  and  database  systems. 
Second,  the  object-oriented  data  model  provides  constructs  that  allow  flexibility, 
modularity,  and  portability,  previously  unavailable  in  other  models.  Finally,  it  is  powerful 
enough  to  model  many  diverse  database  applications,  in  particular  abstract  modeling  such 
as  applications  in  CAD/CAM.  These  final  two  points  make  (X)DM  less  task  specific  than 
conventional  models. 

1.  The  Basic  Constructs  of  OODM 

The  basic  element  of  OODM  is  the  “object”  and  “class”  of  objects.  An  object  can 
be  defined  as  “a  physical  entity,  a  concept,  an  idea,  an  event,  or  some  aspect  of  interest  to 
database  application”  [Booc91].  These  objects  are  grouped  logically  into  “classes”  and 
then  arranged  into  a  hierarchy.  Some  examples  of  objects  may  be  cars,  trucks,  or  vans. 
Similarly,  cars  could  be  grouped  by  types  into  sub-classes  of  sports  cars,  sedans,  and  station 
wagons  which  are  then  grouped  together  into  one  class.  Vehicles. 

With  the  object  as  its  building  block,  (X)DM  comprises  four  major  elements: 
Abstraction,  Encapsulation,  Modularity,  and  Hierarchy  [Booc91].  Abstraction  refers  to  the 
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essential  characteristics  of  an  object  that  distinguish  it  from  all  other  objects.  Returning  to 
the  vehicle  example,  the  extended  passenger/cargo  compartment  distinguishes  a  station 
wagon  from  a  sedan,  and  an  open  bed  distinguishes  a  truck  from  a  sports  car.  Both  are 
examples  of  abstraction. 

Encapsulation  marks  a  revolutionary  feature  of  CX)DM.  Rather  than  store  the 
data  separately  from  the  program,  as  in  conventional  database  systems,  die  object-oriented 
data  model  stores  the  data  with  the  program;  i.e.,  these  programs,  called  the  methods  (or 
actions),  to  be  applied  to  the  data  are  stored  entirely  within  the  object  This  encapsulation 
of  the  methods  allows  only  legitimate  operations  to  be  performed  on  that  object  thus  pre¬ 
serving  data  integrity. 

Modularity  is  a  direct  by-product  of  the  object  structure  and  the  encapsulation 
characteristic.  Because  each  object  contains  the  methods  necessary  to  operate  on  that 
object  the  object  can  stand  alone  or  be  moved  to  other  parts  of  the  database.  Modularity 
and  portability  go  hand-in-hand. 

Finally,  the  hierarchical  structure  gives  rise  to  the  notion  of  inheritance.  Inherit¬ 
ance  is  the  key  to  object-oriented  design  and  functionality.  The  object  A  is  said  to  inherit 
from  the  object  B  if  the  object  A  retains  the  same  characteristicsj.e.,  data  or  methods,  as 
the  object  B.  Graphically,  the  object  B  is  located  above  the  object  A  in  the  inheritance  hier¬ 
archy.  There  are  two  types  of  inheritance.  Data  inheritance  occurs  if  A  inherits  all  the 
attributes  of  B  whereas  operational  inheritance  occurs  when  A  inherits  all  the  methods  (or 
actions)  of  B. 

Inheritance  is  most  naturally  thought  of  as  the  “a-kind-of  ’  relationship.  For 
instance,  a  sports  car  is  a-kind-of  car,  which  is  a-kind-of  vehicle.  The  benefit  of  inheritance 
is  that  the  methods  and  data  of  “higher”  classes  of  objects  arc  passed  to  those  “lower”  in 
the  hierarchy.  If  method  describing  tire  rotation  is  pertinent  to  all  three  types  of  vehicles, 
i.c.,objects,  then  it  is  only  declared  in  the  object.  Vehicle.  Any  object  further  down  the 
Vehicle  hierarchy  inherits  the  tire  rotation  method.  This  requirement  is  depicted  in  Figure 
1. 
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NUMBER  SEATING 
OF  DOORS  CAPACITY 


VEHICLE  contains  the  attributes  COLOR  and  PRICE  and  the  method  TIRE 
ROTATION.  AUTOMOBILE  and  TRUCK  inherit  the  attributes  and  methods  of 
VEHICLE.  SEDAN  and  SPORTS  CAR  inherit  the  attributes  and  methods  of 
VEHICLE  and  AUTOMOBILE.  PICK-UP  inherits  the  attributes  and  methods 
of  VEHICLE  and  TRUCK. 


Figure  1:  An  Example  of  the  Inheritance  Hierarchy 


2.  OODM  As  a  Database  Model 

Abstraction,  encapsulation,  modularity,  and  inheritance  make  OODM  the  ideal 
data  model  for  sophisticated  database  applications.  OODM  offers  a  number  of  advantages 
when  compared  to  traditional  data  models.  First,  OODM,  unlike  the  relational  data  model, 
does  not  rely  on  the  use  of  foreign  keys  in  the  manipulation  of  data.  A  foreign  key  is  a  key 
attribute  which  refers  from  one  relation  to  another  and  its  use  or  misuse  may  violate  the 
referential  integrity.  Both  relations  must  share  the  same  domain  for  these  attribute  values. 
Instead  of  foreign  keys,  OODM  uses  the  opo'adonal  inheritance  and  the  data  inheritance  to 
implement  generalization  and  specialization.  These  inheritance  properties  maintain  the 
data  integrity  constraints  within  OODM.  Thus,  not  only  does  OODM  eliminate  the 
overhead  required  to  maintain  the  foreign  keys,  it  also  minimizes  the  “dangling-key 
phenomenon”  which  violates  the  referential  integrity  of  the  foreign  key.  This  phenomenon 
occurs  when  records  referred  to  by  the  foreign  keys  are  removed  [Hsia92c]. 

Second,  the  hierarchical  data  model  and  OODM  both  use  a  hierarchical  data 
stmcture.  The  hierarchical  data  model  differs  from  OODM  because  it  uses  hierarchies  that 
are  arbitrary  in  nature.  The  hierarchies  are  arbitrary  because  they  are  developed  by  the 
programmer  when  the  database  is  created.  Hiis  may  or  may  not  be  based  on  logical  or 
natural  hierarchies,  and  may  change  with  time  from  one  programmer  to  the  other 
programmer.  OODM,  however,  uses  the  inheritance  property  to  create  the  hierarchies. 
Thus,  they  are  more  natural  and  less  arbitrary  than  those  found  in  the  hierarchical  data 
model  [Hsia92c]. 

Finally,  the  network  data  model,  like  the  hierarchical  data  model,  uses  hierarchies 
that  are  arbitrary  in  nature.  Yet,  it  differs  from  the  hierarchical  model  because  two 
hierarchies,  rather  than  one,  are  used  to  model  a  relationship  between  two  record  sets.  This 
introduces  confusion  into  the  database  design  making  database  management  more  difficult 
to  build  and  use  [Hsia92c]. 

As  discussed  above,  the  traditional  data  models  suffer  from  serious  shortcomings. 
Furthermore,  they  are  better  suited  for  modelling  specific  tasks  and  concepts.  OODM  is 
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naturally  suited  for  modelling  complex  and  general  concepts.  With  the  traditional  data 
models,  the  database  designer  must  convert  the  conceptual  design  into  an  actual  database. 
In  the  traditional  procedure,  the  conceptual  design  may  have  some  of  its  features  sacrificed 
in  order  to  meet  the  specifications  of  the  database.  On  the  otho’  hand,  OODM  allows  the 
database  designer  to  move  directly  from  the  abstract  and  conceptual  design  to  a  fimctioning 
database,  without  corrupting  the  original  concept 

Object-oriented  databases  can  offer  advantages  in  q)eed.  Unlike  the  relational 
model,  joins  are  not  used  in  the  OODM.  This  is  because  the  object  can  be  directly  found 
using  object  IDs  rather  than  using  time-consuming  search  techniques.  Also  the  inhmtance 
property  insures  that  data  are  passed  to  lower  objects  in  the  hierarchy  thus  eliminating  the 
need  for  a  join.  Because  the  same  data  model  is  used  by  the  database  and  the  database 
programming  language,  format  conversions  at  the  disk-level  are  not  required.  This  in  turn 
helps  speeding  up  the  reading  of  data  from  the  disk  and  the  storage  of  data  on  the  disk. 

C.  THE  COVERING  CONSTRUCT 

There  are  various  forms  of  object-oriented  databases  in  existence.  The  proliferation 
of  the  OODM  constructs  stems  from  a  lack  of  the  standard  similar  to  those  found  in  other 
data  models.  The  majority  of  the  OODB  design^s  agree  that  the  inheritance  is  an  important 
characteristic  of  the  object-oriented  database.  Another  construct  found  in  object-oriented 
data  models  is  the  covering  property.  Covoing  (or  aggregation)  is  the  means  by  which  an 
object  in  one  hierarchy  can  relate  to  a  class  of  objects  in  another  hierarchy.  As  explained  in 
[Hsia92c]  that,  “we  say  A  is  a  cover  of  B  if  every  object  of  A  corresponds  to  a  subset  of 
objects  of  B.”  In  mathematical  terms,  this  means  that  the  object  class  A  is  related  to  the 
power  set  of  the  object  class  B,  though  no  “hard-wired”  structures  exist  between  them. 

The  covering  property  does  not  enjoy  the  same  amount  of  popularity  as  the 
inhmtance  in  the  object-oriented  database  community.  This  is  a  carry-over  from  object- 
oriented  programing  where  programmers  did  not  want  interaction  between  sqrarate  object 
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hierarchies.  In  programming,  encapsulation  prevents  corruption  of  an  object  module  by 
another  objea  module.  This  concq>t  does  not  necessarily  hold  with  database  applications. 
Encapsulation  can  prevent  the  sharing  of  data  between  objects.  Covering  is  designed  to 
overcome  this  limitation.  It  will  be  shown  that  covering  allows  more  flexibility  in  accessing 
and  manipulating  data  within  an  object-oriented  database. 

Perhaps  the  easiest  way  to  visualize  the  covering  property  is  to  use  the  in-law 
relationship  between  two  family  trees.  Two  hierarchies  (family  trees)  are  related  when  a 
son  of  one  set  of  parents  marries  the  daughter  of  another  set  of  parents.  This  marriage 
illustrates  the  utility  of  the  covering  property.  Though  not  related  by  blood,  there  is  now  a 
recognized  relationship  between  the  groom  and  the  bride’s  parents  which  are  called  the 
mother-in-law  and  father-in-law.  The  same  is  true  for  the  bride.  Similarly,  from  the  parent’s 
perspective,  there  is  a  “downward”  relationship  of  the  daughter-in-law  and  son-in-law.  If 
this  covering  relationship  is  not  introduced  into  OODM,  it  will  be  difficult  for  the  members 
of  two  family  trees  to  be  related  through  the  marriage. 

Now  we  apply  the  covering  property  to  a  database.  Suppose  the  family  tree  structure 
exists  as  described  above.  The  inheritance  alone  allows  each  child  to  access  the  birth  date 
of  anyone  within  his  family  tree.  Since  the  new  husband  is  not  part  of  diat  hierarchy,  he 
cannot  access  information  on  his  in-laws.  With  the  covering  property,  this  is  not  only 
possible,  but  other  members  of  the  opposite  family  tree  can  also  do  the  same.  This  is  a  very 
powerful  construct  uruque  to  the  objea-oriented  data  model.  Without  the  covering 
propmy,  independent  hierarchies  within  a  single  database  cannot  be  manipulated  as  a 
whole.  See  Figure  2  for  an  illustration  of  two  family  hierarchies  based  on  the  inheritance 
property  and  one  in-law  relationship  based  on  the  covering  proper^. 

To  reiterate,  we  point  out  that,  unlike  the  inheritance  property,  the  covering  property 
has  not  enjoyed  the  same  widespread  acceptance  within  the  OODB  community.  In  fact, 
covering  has  not  been  fully  implemented  into  any  working  databases  to  date.  Consequentiy, 
there  is  a  need  to  prove  the  viability  of  this  construct  and  demonstrate  its  usefulness.  This 
thesis  will  focus  on  the  implementation  of  the  covering  propoty  into  the  object-oriented 
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TODD  and  PAULLA  are  married  and  create  a  marriage  relationship.  The  cover¬ 
ing  construct)  IN-LAW,  allows  TODD  to  acc^  the  Date  of  Birth  of  each  member  of 
PAULLA*s  h  Mill  j.  If  the  IN-LAW  property  did  not  exist,  TODD  could  not  access  this 
information. 


Figure  2:  An  Example  of  the  Covering  Property  Through  the  In-Law  Relationship  of 

Two  Family  Trees 


data  model  of  the  Multimodel  and  Multilingual  Database  System  (M^DBMS).  Specifically, 
the  thesis  will  address  the  questions  of  feasibility,  practicality,  and  usefulness  of  the 
covering  property  of  OODM.  The  end  product  will  be  a  working,  dononstrable  objea- 
oriented  database  interface  for  an  application  using  the  covoing  construct 

D.  ORGANIZATION  OF  THE  THESIS 

In  Chaptor  II  of  this  thesis,  we  provide  an  overview  of  the  hardware  and  software  of 

the  Multibackend  Database  Supercomputer  (MDBS)  on  which  M^DBMS  runs.  In  Chapter 
m,  we  describe  the  implementation  issues  regarding  the  object-oriented  data  model  in 
MDBS.  The  details  and  design  of  implementing  the  covering  property  into  OODM  is  the 
subject  of  Chapter  IV.  Chapter  V  discusses  additional  modifications  made  to  the  object- 
oriented  interface  on  MDBS  as  well  as  the  limitations  which  exist  within  the  interface. 
Future  work  need  on  the  object-oriented  int^ace  in  MDBS  is  detailed  in  Qiapter  VI.  In 
Chapter  VII,  we  summarize  our  conclusions.  The  appendices  contain  relevant  illustrations, 
program  logic,  and  a  tutorial  for  the  object-oriented  interface  on  MDBS. 
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n.  A  DESCRIPTION  OF  MDBS 


A.  THE  CASE  FOR  FEDERATED  DATABASES  AND  THE  MULTIBACKEND 
DATABASE  SUPERCOMPUTER  WITH  THE  MULTIMODEL  AND 
MULTILINGUAL  CAPABILITIES 

The  growth  and  proliferation  of  computers  within  business  and  industry  has  resulted 
in  their  involvement  in  nearly  every  2spcct  of  the  business  life.  Each  con^any,  or 
dq>artment  within  a  company,  accumulates  and  maintains  different  data  types  according  to 
their  own  particular  needs.  This  accumulation  of  data  in  multiple  forms  causes  redundancy 
and  inefficiency. 

To  illustrate  this  point,  let  us  view  a  company  composed  of  many  departments,  each 
using  a  specialized  database  for  its  operations  Pisia92b].  The  personnel  department, 
concerned  with  payroll-and-record  keeping,  might  use  a  relational  database  to  keep  track 
of  en^loyee  records.  The  engineering  department  might  use  the  software  running  a 
hioarchical  database  because  it  is  most  naturally  suited  for  engineered  assemblies. 
Shipping  and  inventory  control  is  accomplished  using  the  network-model  software  due  to 
the  ease  of  representing  the  many-many  relationships.  The  end  result  is  that  each 
department  uses  a  “homogeneous”  database  for  its  own  particular  use;  yet  together,  they 
form  a  “heterogeneous”  database  because  they  use  different  models  and  languages. 
Naturally,  this  contributes  to  needless  duplication  of  data  which  are  common  to  all 
departments.  Moreover,  since  each  department  uses  a  different  model,  data  cannot  be 
shared  among  departments.  The  lack  of  data  sharing  among  die  departmr  its  is  due  to  the 
fact  that  die  modeled  data  are  foreign  to  the  user  of  another  department  Also,  as  mentioned 
previously,  users  in  each  department  will  become  familiar  with  their  own  particular  model/ 
language  and  thus  be  limited  to  locally  available  data  only. 

If  the  same  company  now  wishes  to  open  several  odier  plants  and  offices  around  the 
country,  then  the  ability  of  each  department  or  company  division  to  share  data  is  crucial  for 
planning,  implementing,  and  meeting  corporate  strategies  and  goals.  Qearly  duplicating  all 
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the  databases  into  different  forms  on  the  basis  of  various  heterogeneous  data  models  is 
inefficient;  yet,  purely  centralized  control  requires  a  common  type  of  database  and  nKxlel. 
The  solution  to  the  aforementioned  two  extreme  measures  is  a  federated  or  multidatabase 
structure.  In  a  federated  database  or  a  multidatabase  an  user  believes  the  user  is  using  the 
user’s  own  database  with  the  user’s  favorite  language,  yet  the  actual  data  may  be  located 
elsewhere,  based  on  a  different  data  model  and  part  of  a  larger  database  system.  A  federated 
database  permits  sharing  of  data,  wider  availability,  and  optimal  use  of  assets.  Federated 
database  systems  are  actually  a  hybrid  between  a  centralized  and  distributed  systems 
[Elma89]. 

In  order  to  establish  a  federated  database  with  efficient  data  sharing,  the  following 
five  conditions  must  be  met  [Hsia92b]; 

1.  Transparent  access  to  heterogeneous  databases.  An  user  should  be  able 
to  access  any  data  using  the  model  and  language  most  familiar  to  the  user.  For  example,  the 
director  of  engineering  may  want  to  study  the  inventory  of  the  most  recently  designed 
product  Rather  than  learn  CX)DASYL-DML  transactions  to  access  the  network  database, 
he  or  she  may  use  the  more  familiar  DL/I  transaction  to  access  the  data  maintained  by  the 
shipping  department 

2.  Local  autonomy  of  each  heterogeneous  database.  This  condition  allows 
an  owner  to  share  the  database  with  others  without  compromising  the  owners  own  integrity 
or  security  constraints.  Continuing  with  our  previous  example  where  the  director  of 
engineering  may  view  the  data,  he  or  she  is  not  allowed  to  change  the  data.  The  ability  to 
change  the  data  is  retained  by  the  owner,  who  in  this  case  is  the  shipping  and  receiving 
departmental  manager. 

3.  Federated  databases  are  multimodel  and  multilingual.  Multimodel 
means  that  the  database  supports  many  different  models.  In  our  company  example,  the 
federated  database  would  have  to  support  the  relational,  hierarchical,  and  network  models. 
Multilingual  means  that  each  transaction  made  on  the  database  can  be  made  using  any 
language  applicable  to  the  models  supported  by  the  system.  Thus,  the  company  is  able  to 
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support  all  three  rmidels  while  executing  transactions  written  in  SQL,  CX)DASYL-DML, 
and  DL/I  on  their  respective  databases. 

4.  Multibackend  Capability.  This  requirement  is  q>ecifically  aimed  at 
resource  consolidation.  Rather  dian  let  all  of  the  software  and  database  run  in  existing 
computers  in  a  multi-system  environment,  a  specialized  computer  syston,  with  many 
parallel  backends  is  used  to  run  the  multimodel  and  multilingual  software  and  to  store  all 
the  databases.  These  backends  are  actually  special-purpose  database  computers  diat  are 
dedicated  to  supporting  the  database  application.  Efficiency  is  attained  through  the  use  of 
multiple  backends  linked  in  parallel.  This  parallelism  induces  high  speed  and  great 
capacity. 

5.  Effective  and  Efficient  access  and  concurrency  control  mechanisms. 
Because  the  wider  access  to  the  database  allowed  by  the  multimodel/multilingual 
capability,  there  exists  a  great  potential  to  violate  integrity  and  security  constraints  in  a 
multi-system  enviromnent  However,  despite  the  large  number  of  backends  and  high 
degree  of  parallelism,  the  multibackend  is  in  a  single  system  or  uni-system  environment 
We  know  how  to  safeguard  the  integrity  and  security  of  databases  in  the  uni-system 
environment 

As  can  be  seen  above,  these  requirements  dictate  the  use  of  specialized  hardware  and 
software.  The  parallel,  multibackend  computers  are  required  for  capacity  and  efficiency. 
Specialized  software  for  interpreting  multiple  models  and  languages  is  necessary  to  ensure 
universal  compatibility  among  users  while  still  preserving  data  integrity  and  security 
constraints.  The  database  research  laboratory  at  the  Naval  Postgraduate  School  (NPS) 
combines  both  features  into  one  system  utilizing  a  multibackend  supo’computer  with  the 
multmxxlelAnultilingual  software. 
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B.  THE  MULTIBACKEND  DATABASE  SUPERCOMPUTER  (MDBS) 


The  Multibackend  Database  Supercomputer  (MDBS)  in  the  NPS  database  laboratory 
consists  of  one  controller  computer  and  six  backend  computers.  The  backend  computers  are 
connected  to  the  controller  by  an  ethemet  local  area  network  (LAN).  Figure  3  illustrates  the 
MDBS  configuration.  This  system  offers  two  significant  advantages.  (1)  The  reduction  in 
response  time  for  a  given  query  varies  inversely  in  proportion  with  the  numba  of  backend 
computers;  and  (2)  if  the  number  of  backends  increases  proportional  with  die  aze  of  die 
database,  then  there  is  litde  change  in  the  query  response  time  [Meek93].  Thus,  the  number 
of  backends  is  the  deciding  factor  in  determining  transaction  response  time.  In  other  words, 
MDBS  is  scalable  for  the  desired  responses. 

The  controller  computer  is  an  off-the-shelf  Sun  model  4/1 10  workstation  utilizing  the 
Sparc  4  RISC  architecture,  with  8  megabytes  of  RAM  and  one  373-megabyte  hard  drive 
[Meek93].  The  controller’s  primary  purpose  is  to  provide  communication  between  the 
backends  and  act  as  the  interface  between  the  user  and  the  system.  Unlike  the  backends,  the 
controller  does  not  have  any  database.  However,  in  case  of  a  backend  failure,  the  controller 
can  provide  backup  and  recovery  of  the  database  with  the  use  of  magnetic  tape  [Meek93]. 

The  backends  are  Sun  model  4/280  workstations  also  using  the  Sparc  4  RISC 
architecture.  All  backends  have  identical  hardware  and  software.  This  parallel  architecture 
provides  optimum  speed  and  performance  through  its  scalability,  in  terms  of  response-time 
reduction,  and  the  response-time  invariance  [Bour93].  Each  backend,  being  a  self- 
contained  database  computer,  stores  the  data  on  two  types  of  disks.  Base  data  (raw  data)  is 
stored  on  1000-megabyte  moving-head  disk  while  meta  data  (information  about  the  base 
data)  and  paging  information  are  stored  on  two  96-megabyte  Winchesto’-type  disk  drives, 
reqrectively  [Meek93].  Base  data  are  not  replicated  on  its  disks.  Instead,  they  are 
distributed  by  clusters  of  data  one  cluster  at  a  time  across  the  tracks  of  the  disk  parallel 
drives.  This  clustering  (or  partitioning)  of  the  data  and  evenly  distributing  the  clustered  data 
among  the  backend’s  disks  help  to  achieve  paraUel  access  operations,  because  the  data  is 
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evenly  distributed  among  the  disks  of  all  the  backend  computers  [Hsia92b].  Each  track  is 
accessed  serially,  while  all  the  tracks  for  a  cluster  are  accessed  in  parallel. 

C.  THE  MULTIMODEL/MULTILINGUAL  DATABASE  SYSTEM  (MODEMS) 

To  meet  the  multimodel/multilingual  requirement  of  efficient  federated  databases,  at 
present  MDBS  uses  die  software  capable  of  accessing  a  consolidated  database  in  any  one 
of  four  data  models.  These  models  are  the  relational,  hierarchical,  network,  or  object- 
oriented  data  models.  Further,  each  of  the  first  three  traditional  models  can  be  accessed 
using  their  corresponding  languages,  i.e.,  SQL,  CX)DASYL,  or  DL/I.  The  object-oriented 
model  does  not  have  an  associated  language.  The  primary  feature  of  this  software  is  the 
ability  to  use  any  of  the  above  languages  to  access  the  database.  Furthermore,  some  cross¬ 
model  accessing  capabilities  are  possible  on  MDBS.  Figure  4  describes  the  system  in  detail. 

The  heart  of  the  MDBS  software  is  the  kernel  data  model  (KDM)  and  the  kernel  data 
language  (KDL).  MDBS  uses  the  attribute-based  data  model  (ABDM)  and  its  associated 
attribute-based  data  language  (ABDL)  for  the  kernel  data  model.  The  ABDM  supports  the 
five  primary  database  operations  of  INSERT,  UPDATE,  DELETE,  RETRIEVE,  and 
RETRIEVE  COMMON  [Bour93].  All  data  is  stored  on  the  disk  in  the  kernel  format  Each 
transaction,  regardless  of  model  or  language,  is  translated  into  the  ABDL  equivalent  where 
it  is  processed  and  then  returned  to  the  user  in  the  original  language.  Thus  the  users 
language  is  merely  a  convenient  interface  between  him  and  the  konel  data  model. 

When  the  user  logs  on  to  the  system,  he  chooses  a  model  with  which  to  access  the 
database.  The  chosen  model  is  called  the  user  data  model  (UDM)  and  the  associated 
language  is  called  the  user  data  language  (UDL).  Tlie  UDL  is  how  the  user  commuiticates 
with  the  kernel  data  model. 

Each  data  language  requires  four  software  modules  to  accomplish  tire  translation  into 
the  KDM  equivalent  These  modules  are  the  language  interface  layra  (LIL),  the  kernel 
mapping  system  (KMS),  the  kernel  formatting  system  (KFS),  and  the  kernel  controller 
(KC)  [Meek93].The  relationship  between  die  software  modules  and  the  kernel  system  is 
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Figure  4:  The  Multimodel,  Multilingual  and  Cross-Model  Acces^ng  Capability 
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UDM  :  User  Data  Model 
UDL  :  User  Data  Language 
LIL  Language  Interface  Layer 
KMS  :  Kernel  Mapping  System 
KFS  :  Kernel  Formatting  System 
KC  :  Kernel  Controller 
M/Ll  :  Model/Language  Interface 
KDS  :  Kernel  Datsdsase  System 
KDM  :  Kernel  Data  Model 
KDL  :  Kernel  Data  Language 

Figure  5:  The  Multimodel  and  Multilingual  Database  System 

(M^DBMS) 

described  in  Figure  5  .  Figure  6  illustrates  the  relationship  between  the  different  language 
interfaces.  Each  module  is  described  in  the  following  paragraphs  [Karl93]. 

The  function  of  LIL  is  to  take  the  users  transaction  and  route  it  to  the  appropriate 
module  within  KMS.  The  user  can  access  LIL  by  sending  transactions  via  the  terminal  or 
from  a  mass-load  rile.  LIL  also  controls  the  order  in  which  other  modules  are  called. 

The  KMS  module  supports  two  functions.  First,  it  identifies  whether  or  not  the  user 
is  creating  a  new  database.  If  so,  then  a  data-model  tran^ormation  must  occur.  The  UDM- 
database  definition  is  then  transformed  by  KMS  into  the  KDM-database  definition  so  that 
data  can  be  processed  and  the  database  can  be  created.  With  the  data-model  transformation 
complete,  the  request  can  be  sent  to  the  kernel  controller  (KC).  The  KC  sends  the  newly 
created  KDB-database  derinition  to  the  kernel  dam  system  (KDS)  for  processing.  KDS  then 
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Figure  6:  The  Model-Language  Interfaces  on  MDBS 

notifies  the  MDBS  controller  that  a  new  database  has  been  created  in  the  form  of  UDM. 
Data  can  now  be  entered  by  the  user  as  well  as  queries  against  that  data. 

The  second  function  of  the  KMS  concerns  the  data-language  translation.  Here  the 
UDL  transaction  is  transformed  into  an  equivalent  KDL  transaction  by  KMS.  Once  the 
transaction  has  been  translated,  it  is  sent  to  KC  and  then  on  to  KDS  for  execution.  Thus, 
KMS  performs  the  vital  functions  of  data-model  and  data-language  translation,  which  is 
essential  to  achieving  the  multimodel/multilingual  capability. 

KFS  is  concerned  primarily  with  returning  die  results  of  the  query  to  the  user.  Once 
the  transaction  is  executed  in  KDS,  KFS  takes  the  results  and  accomplishes  the  translation 
from  the  KDM  form  back  to  the  UDM  form.  KFS  then  routes  the  transaction  back  to  LIL 
for  display  to  the  user. 

KC  takes  all  ABDL  transactions  and  passes  them  to  the  kernel  system  for  execution. 
The  nature  of  the  transaction  determines  where  it  is  sent  by  KC  once  query  processing  is 
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complete.  If  the  transaction  concerns  an  update,  insertion,  or  deletion  to  the  database  then 
control  reverts  to  UL  upon  completion  of  the  transaction.  If  the  transaction  is  a  retrieve 
request,  then  KC  routes  the  request  to  KDS,  which  processes  it  and  then  sends  the  result 
back  to  KC.  KC  then  takes  the  result  and  places  it  in  a  buffer  for  KFS  which  then  displays 
the  result  to  the  user  [Karl93]. 

D.  SUMMARY 

The  need  for  accurate  and  rapid  access  to  large  heterogeneous  databases  is  an 
universal  problem  facing  business,  industry,  and  government  Efficient  management  of 
vast  quantities  of  data  calls  for  the  use  of  a  federated  database  structure.  In  order  to  meet 

this  challenge,  specialized  computers  and  software  are  necessary.  MDBS  with  M  DBMS 
offers  one  effective  and  efficient  way  of  sati^ying  these  requirements.  The  use  of  multiple 
backends  in  a  supercomputer  dedicated  for  the  database  provides  speed  and  efficiency  in 
database  access  and  storage.  The  specialized  software  providing  muldmodel/multilingual 
capabilities  allows  wider  use  and  greater  access  among  the  heterogeneous  database  users. 
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in.  THE  OBJECT-ORIENTED  MODEL  ON  MDBS 


Tlie  object-oriented  model  is  implemented  on  MDBS.  This  iinplementation  strategy 
has  two  advantages.  First,  an  entire  database  system  is  not  require  to  be  written  from  the 
scratch.  Only  the  object-oriented  interface  is  required.  This  results  in  a  savings  of  time  and 
resources.  Second,  by  implementing  the  object-oriented  database  into  multilingual/ 
multimodel  system,  we  preserve  the  interop^ability  of  the  heterogeneous  database.  This 
allows  data  sharing  among  the  installed  interfaces. 

The  interface  design  for  the  object-oriented  model  on  MDBS  closely  parallels  the 
design  for  the  relational  model  [Roll84].  As  in  the  relational  implementation,  the  primary 
data  structure  used  is  the  linked  list  This  structure  is  used  because  it  dynamically  connects 
related  objects  together  and  makes  a  hierarchical  (tree)  structure  possible. 

Each  object  being  created  is  a  record  called  an  object-class  node  (ods_node).  Hiese 
object-class  nodes  are  connected  via  pointers  to  form  a  linked  list  of  other  objects.  Within 
each  object  of  an  object-class  node,  there  are  attributes  ^)ecifrc  to  that  object  and  pointers 
connecting  a  list  of  attributes  and  pointers  relating  that  node  to  other  class  nodes  in  the  list 
Refer  to  Figure  7  for  the  layout  of  the  object  class  data  structure. 

The  attribute  ocn^name  contains  the  name  of  the  object  while  the  attribute 
ocn_nuin_aUr  holds  the  total  number  of  attributes  for  the  object  The  attributes 
ocn_supcls  and  ocn__^subcls  contain  the  number  of  the  object’s  superclass  and  subclass 
respectively. 

The  six  pointers  in  ocls_node  form  a  connection  between  the  object’s  attributes  as 
well  as  its  relationship  between  its  superclasses  and  subclasses.  The  pointer 
ocn_firstjsupcIs  points  to  the  object’s  immediate  superclass  while  ocn_curr_supds 
points  to  the  next  sup^lass  in  the  list  of  superclasses  for  that  object  Similarly  the  pointers 
ocn_firstj5ubcls  and  ocn_curr_subcls  point  to  the  object’s  subclasses.  Ocn_first_attr 
and  ocn_curr_attr  point  to  the  object’s  first  attribute  and  subsequent  attributes 
respectively.  See  Figure  19  in  Appendix  A.  for  a  diagram  of  ocls_node. 
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stractods  node 
{ 

char 

ocn_name[RNLength  + 1]; 

int 

ocn_num_attr; 

int 

ocn_supcls; 

int 

ocn.subcls; 

strua  o_supcls_node 

*ocn_first_si^ls; 

struct  o_supcls_node 

♦ocn_cuir_supcls; 

struct  o_subcls_node 

♦ocn_first_subcls; 

struct  o_subcls_node 

*ocn_curr_subcls; 

struct  oattr.node 

*ocn_first_attr. 

struct  oattr_node 

*ocn_curr_attr; 

struct  ocls  node 
} 

♦ocn_next_cls; 

Figure  7:  The  Object-Ciass-Node  Data  Structure 

All  attributes  are  contained  in  the  object-attribute  node.  For  objects  with  multiple 


attributes,  these  nodes  are  connected  to  form  a  linked  list  of  attributes.  Special  nodes  called 
object-superclass  nodes  and  object-subclass  nodes  are  created  to  form  a  hierarchy  within 
the  linked  list  These  nodes  form  the  basis  of  the  inheritance  construct  and  are  also  the  basis 
for  developing  the  new  covering  construct  The  object-class  node  is  the  primary  node, 
which  contains  pointers  to  other  secondary  nodes  that  form  the  hierarchical  linked  list 
These  secondary  nodes  are  discussed  in  detail  below  [Karl93]. 

1.  Object-attribute  node.  Oattr_node  forms  the  elements  of  a  linked  list 
connecting  all  the  attributes  relevant  to  a  particular  object  Each  object  attribute,  such  as 
name,  birth  date,  salary,  and  so  on  is  individually  located  in  a  different  object-attribute 
node.  Within  this  node  are  three  attribute  fields  and  one  linking  pointo:.  The  attribute  name 
(for  example,  birth  date)  is  located  in  attribute  field  oan^name.  The  data  type  (i.e., 
character,  integer,  etc.)  of  the  particular  attribute  name  is  located  in  the  attribute  tield 
oan_type.  The  length  of  the  attribute  name  is  contained  in  the  attribute  field  oanjoigth. 
The  linking  pointer  in  the  node,  called  oan_next_attr,  points  to  the  next  attribute  in  the 
linked  list  of  attributes.  This  is  used  for  objects  with  multiple  attributes.  Figure  8  shows  the 
layout  of  the  attribute-node  data  structure. 
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struct  oattr  node 
{ 

char 

oan_name[ANLength  + 1]; 

char 

oan_typc[RNLength  + 1]; 

int 

oanjength; 

strua  oattr_node 
} 

*oan_ncxt_attr. 

Figure  8:  The  Object-Oriented  Attribute-Node  Data  Structure 

2.  Object-superclass  node.  This  node  is  called  o_supcls_node.  It  is  the 
connecting  point  for  each  object  to  its  superclass.  The  only  attribute  within  this  node  is  the 
name  associated  with  the  superclass,  osn^name.  Two  pointers  are  contained  within  this 
node.  One  pointer,  osn_supcls,  connects  the  node  to  a  superclass,  while  another  pointer, 
osn_next_supcls,  points  to  the  next  superclass  in  the  linked  list  of  superclasses  pertaining 
to  that  particular  node.  The  ability  of  the  object  to  have  more  than  one  superclass  allows  for 
the  multiple  inheritance.  The  superclass  node  data  structure  is  described  in  Figure  9. 


struct  0  supcls  node 

{- 

char 

osn_name[RNLcngth  + 1]; 

struct  ocls.nodc 

*osn_supcls; 

struct  0  supcls  node 

} 

*osn_next_supcls; 

Figure  9:  The  Object-Oriented  Superclass-Node  Data  Structure 

3.  Object-subclass  node.  This  node  is  called  o_subds_node.  It  is  similar  in 
structure  to  the  superclass  node.  The  attribute  osn_naine  lists  the  name  of  the  node,  while 
the  pointers  osn_subcls  and  osn_nextjsubcls  link  the  object  with  its  subclasses.  See 
Figure  10.  Figures  20  through  22  in  Appendix  A.  illustrate  how  these  three  nodes  are 
linked  together. 
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struct  o  subds  node 
{" 

char  osn_nantt[RNLength  1]; 

struct  ocls_node  *osn_subcls; 
struct  o_subcls_nodc  *osn_ncxt_subcls; 

} 

Figure  10:  The  Object-Oriented  Subclass-Node  Data  Structure 

A.  THE  INHERITANCE  PROPERTY  IN  MDBS 

Inheritance  in  the  objea-oriented  model  is  accomplished  through  the  object- 
superclass  node  and  the  object-subclass  node  and  their  interconnections  widi  object  class 
node.  When  an  object  is  first  created,  pointo-s  within  these  nodes  are  initialized  as  null.  As 
subsequent  objects  are  created,  these  nodes  will  point  to  objects  located  higho’  or  lower  in 
the  hierarchy.  For  example,  if  object  B  is  to  become  a  member  of  the  subclass  of  object  A, 
then  the  following  pointers  will  be  set  The  first  subclass  pointer  (ocn_first_subcls)  within 
object  A’s  object  class  node  will  point  to  the  newly  created  object  subclass  node 
(ocn_subds_node).  This  node  will  in  turn  point  to  the  object-class  node  (ods.node) 
belonging  to  B.  Similarly,  the  corresponding  superclass  nodes  and  pointers  will  connect 
objea  B  op  to  object  A. 

Attributes  are  inherited  downward  widiin  the  hierarchy.  Lower  objects  contain  all  of 
the  attributes  ascribed  to  objects  located  above  it,  as  well  as  those  attributes  specific  to  that 
particular  object  The  object-oriented  model  on  MDBS  accomplishes  this  by  using  nested 
linked  lists.  Each  object  node  contains  a  pointer  to  a  linked  list  containing  all  of  the 
attributes  pertaining  to  that  object  Because  each  object  is  connected  to  other  objects  in  the 
hiorarchy  via  the  superclass  and  subclass  pointers,  the  objects  themselves  form  a  linked  list 
Thus,  as  the  hierarchy  is  traversed  downward,  the  linked  list  of  attributes  grows  longer  as 
each  linked  object  is  scanned.  This  is  best  illustrated  by  way  of  example. 

Object  A  contains  the  attributes  name,  address,  and  birth  date.  Object  B,  in  a  subclass 
of  A,  contains  the  attributes  salary  and  employee  number.  As  mentioned  before,  each  of 
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diese  attributes  are  individually  located  in  a  special  object  attribute  node  (oattr_iiode). 
These  nodes  are  dioi  linked  together  into  a  linked  list  Thus,  the  attribute  linked  list  for  A 
will  include  Name,  Address,  and  Birth  Date.  The  pointer  called  ocn_first_attr,  located 
within  object  A*s  object  class  node,  will  point  to  the  first  attribute  on  diat  list 

Object  A’s  rirst  subclass  pointer  (ocnjffrst_subds)  will  point  to  the  object-class 
node  of  B.  A  query  requesting  die  name,  address  and  salary  of  B  will  rirst  traverse  the  list 
of  A's  attributes,  and  retrieve  the  attribute  nodes  of  name  and  salary.  Then  it  will  drop  to  B 
via  the  subclass  pointer,  traverse  the  list  of  B’s  attributes,  and  retrieve  die  salary  attribute 
node  The  linked  list  of  retrieved  attribute  nodes  for  B  consists  of  Name,  Address,  and 
Salary.  The  result  is  that  die  name  and  address  attribute /ie/ris  are  inherited  from  A  and 
linked  with  the  attribute  frelds  of  B.  Values  for  each  of  these  fields  are  then  found  by 
accessing  the  ABDL  record  for  object  B. 

The  inheritance  feature  is  ideally  suited  to  take  advantage  of  the  hierarchical  tree 
structure.  Attributes  of  any  object  can  be  accessed  by  searching  the  tree  for  that  particular 
object,  then  using  the  subclsb^  pointers  to  access  die  attribute  linked  list  This  method  will 
not  work,  however,  when  a  query  involves  objects  from  two  differoit  hierarchies. 
Traditional  inheritance  will  not  work  because  there  is  no  defrned  linkages  from  one  the 
hierarchy  to  another  hierarchy.  Without  such  a  mechanism,  the  cross-hierarchical  query 
processing  is  impossible.  In  other  words,  inheritance  is  a  necessary  but  not  a  sufficient 
feature  of  the  object-oriented  data  model.  Hence  the  object-oriented  model,  as  initially 
implemented  on  MDBS,  is  inadequate  for  realistic  database  scenarios.  The  covering 
property  solves  this  problem  by  providing  a  mechanism  for  an  object  in  one  hierarchy  to 
access  data  in  anodier  hiaarchy. 

B.  THE  COVERING  PROPERTY  ON  MDBS 

Implementation  of  the  covering  property  of  the  object-oriented  model  into  M^DBMS 
on  MDBS  is  the  subject  of  this  thesis.  The  details  and  specific  methodology  are  included 
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in  Qiaptn  four.  For  continuity  purposes,  however,  a  brief  overview  of  the  implementation 
is  given  below. 

The  covering  property  is  implemented  into  the  existing  object-oriented  mo^L  It  uses 
the  same  constructs  as  inheritance,  such  as  pointers  and  linked  lists,  to  achieve  cross- 
hierarchical  mapping.  Once  the  user  logs  onto  Ae  system  and  chooses  the  object-oriented 
model,  he  is  presented  with  an  option  of  “establishing  a  covering  relationship.”  Once 
selected,  the  initial  menu  cascades  into  the  covering  menu.  Here,  the  user  is  asked  to  name 
the  covering  object  and  select  the  class  of  objects  to  be  covered.  The  user  is  dien  queried  as 
to  the  number  of  levels  in  the  hierarchy  to  which  the  covering  relationship  will  apply.  The 
number  of  levels  determines  the  scope  of  the  covering  relationship  onto  the  otho*  hierarchy. 
Our  new  software  then  establishes  the  relationship  and  maps  the  covered  objects  to  a 
database. 

The  database  contains  a  listing  of  the  covoring  construct’s  name,  initial  object,  die 
target  object,  followed  by  all  of  the  covered  objects  that  have  been  mapped.  Subsequent 
queries  by  one  object  of  one  hierarchy  to  an  object  of  another  hierarchy  are  first  checked  to 
see  if  they  belong  to  the  sanw  hierarchy.  If  so,  then  pure  inheritance  will  suffice  to  satisfy 
the  query.  If  the  objects  belong  to  different  hierarchies,  then  the  data  tile  is  checked  to  see 
if  a  covering  relationship  exists  that  covers  the  other  object  If  such  a  relationship  exists, 
then  pointers  are  used  to  access  the  relevant  hierarchy.  The  query  is  answered  as  usual  in 
the  object-oriented  interface.  If  no  covering  relationship  exists,  then  the  query  is  refused 
and  the  user  is  notified  that  the  requested  quay  cannot  be  executed.  The  user  then  has  the 
option  of  establishing  a  covering  relationship  or  exiting  the  menu. 
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IV.  IMPLEMENTATION  OF  THE  COVERING  PROPERTY 

The  covering  property  is  implemoited  in  the  object-oriented  data  model  on  MDBS. 
Q)nseqoently,  it  is  meant  to  supplement  and  enhance  OODM.  Every  effort  was  made  to  use 
die  existing  data  constructs  and  original  code  as  written  by  Karlider  and  Moore  [Karl93]. 
This  was  done  in  order  to  presave  continuity  and  data  integrity.  Where  changes  became 
necessary  in  the  constructs,  notations  were  made  in  the  acconqianying  documentation 
describing  the  purpose  and  author  of  the  code. 

This  chapter  will  detail  the  implementation  of  the  covering  property  in  two  ways.  First 
it  will  describe  the  changes  to  the  data  structure  and  then  outline  the  additional  procedures 
diat  make  the  covering  work.  Second,  it  will  tidte  the  lestfler  sequentially  through  die 
process  using  an  illustrative  example.  Source  code  for  the  covering  implementation  is 
provided  in  Appendix  B.  A  user’s  guide  to  OODM  on  MDBS  widi  the  new  covering  feature 
is  provided  in  Appendix  C. 

The  basic  building  block  of  the  hierarchy  is  die  object-class  node  (ocls_node).  As 
described  in  the  chapter  m,  this  node  contains  the  variables  and  pointers  necessary  to  form 
subclasses  and  superclasses  within  the  hioarchy.  Two  changes  have  been  made  to  the 
ocls_iiode  in  order  to  form  the  covering  relation.  A  new  variable  called  ocn_nuirfced  and 
a  new  pointer  called  coverlets  have  been  t^ded.  Hgure  1 1  illustrates  these  changes. 

Ocn^marked  is  a  boolean  variable  and  is  used  when  travosing  the  hierarchy.  This 
switch,  originally  set  to  false,  is  set  to  true  whenever  an  object  in  the  hierarchy  is  visited  in 
the  search.  The  ocn  jmarked  variable  is  set  when  a  member  of  die  covered  class  of  objects 
is  encountaed  in  a  hierarchical  search.  Once  the  search  is  complete  or  die  system  is  turned 
off,  ocn^marked  returns  to  false.  This  allows  additional  or  new  covering  relations  to  be 
formed  using  a  “fresh”  hierarchy. 

The  coverjds  pointer  is  used  to  point  from  the  object  initiating  the  covering 
relationship  to  the  highest  object  in  the  hierarchy  which  falls  within  die  scope  of  the 
covering  relation.  The  actual  height  in  the  receiver’s  hierarchy  is  determined  by  the  scope 
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ods^node 


ocn^name 

ocn_wpcis 

ocn^subds 

oai  first  supds 

ocn  curr  supds 

ocn  first  subds 

ocn  first  attr 

ocn  curr  attr 

ocn_nextjds  _ 

J 

Figure  11:  The  Modified  Object-Class  Node 

of  the  covering  construct,  which  is  specified  by  the  user.  The  cover_cis  pointer  can  only 
point  to  another  node  of  the  Qrpe,  ocls_node. 

A.  NAMING  THE  COVERING  RELATION 

When  the  user  decides  to  form  a  coveting  relation,  the  system  will  inonq>t  him  to  name 
the  relation.  The  name  serves  two  purposes.  Hrst,  it  gives  a  logical  meaning  to  the  linking 
of  the  two  sqrarate  hierarchies.  Second,  it  allows  for  the  formation  of  multiple  covering 
relations,  each  with  different  scope,  purpose,  and  luime.  An  example  of  such  might  be  In¬ 
law,  Btt^ess,  and  Task  Group.  In-law  would  list  those  objects  grouped  by  virtue  of  the 
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maniage  relation^p;  Business  would  list  objects  grouped  by  means  of  a  partnership  or 
other  business  relationship;  Ta^  Group  would  list  objects,  such  as  particular  ships,  that 
have  been  grouped  together  to  form  a  naval  task  group. 

However,  several  relations  may  have  the  same  name.  There  may  be  a  need  for  multiple 
relationships;  each  with  a  different  grouping  of  objects  for  the  same  named  business 
partnership.  This  feature  is  possible  by  resetting  the  ocn_niarfced  variable  to  false  after 
each  covering  relationship  is  built 

Once  the  name  is  entered  by  the  user,  it  will  become  the  first  item  in  a  list  stored  in  the 
data  file  called  <FILE  NAME>.cover.  Subsequent  items  on  the  list  are  the  *‘fiom-object”, 
the  “to-object”,  followed  by  all  other  objects  covered  in  the  scope  of  the  newly  formed 
covering  relation.  This  list  is  maintained  in  a  text  file  for  future  access  during  query 
processing.  Each  item  of  the  list  is  separated  by  spaces  to  facilitate  parsing  during  the  query 
phase. 

B.  ESTABLISHING  THE  RELATION 

The  basis  for  the  covering  construct  is  the  dining  relation,  which  links  the  two 
separate  hierarchies  together.  This  defining  relation  is  what  was  named  by  the  user  as 
described  above.  In  order  to  create  this  relation,  the  following  pointers  are  used; 

struct  ocls_node  *from_ptr, 

♦to_ptr, 

*from_rel_ptr, 

•to_jel_ptr, 

♦tempi, 

♦temp2; 
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1.  Establishing,  originating  and  ternunating  objects. 

After  naming  the  relation,  the  user  is  prompted  to  enter  the  name  of  the  object 
from  which  the  covering  will  be  originated.  This  is  called  the  from.obj.  After  entering  the 
object’s  name,  the  user  is  prompted  for  the  name  of  die  object  to  which  die  covering 
relationship  will  apply.  This  is  called  the  to^obj. 

The  ocls_node  linked  list  is  then  traversed.  At  each  node,  the  filrst  attribute,  called 
ocn_nanie,  is  examined.  If  the  name  matches  from^obj,  then  the  pointers  from_reljptr 
and  temp2  are  both  assigned  to  that  particular  ods_node.  If  the  name  does  not  match,  then 
the  search  moves  to  the  next  node  via  the  ocn_next_ds  pointo'.  The  search  continues  until 
either  the  name  is  matched  or  until  the  end  of  the  list  is  reached.  If  no  match  is  found,  the 
pointers  are  nullified  and  the  user  is  prompted  to  create  a  new  covering  construct 

If  from^^obj  is  found,  the  list  is  again  traversed  from  the  beginning  in  order  to 
search  for  tojobj.  The  same  method  is  used  in  the  search.  Once  the  node  is  found,  the 
pointers  to_^rel_ptr  and  tempi  both  point  to  to_obj.  To  illustrate,  suppose  to_^obj  was 
named  Paulla  and  from_obj  was  named  Todd.  After  the  search,  the  pointers  are  positioned 
as  shown  in  Figure  12. 

2.  Searching  for  objects  of  the  same  hierarchy. 

Once  the  two  objects  have  been  identified,  they  are  checked  to  see  if  they  belong 
to  the  same  hierarchy.  If  they  share  a  common  hierarchy,  there  is  no  need  for  a  covering 
relationship  because  inheritance  will  suffice  to  satisfy  the  query.  To  determine  this,  the 
pointers  to_ptr,  from_ptr,  tempi,  and  temp2  are  used. 

Beginning  at  to_obj,  the  hierarchy  is  traversed  “upward”  via  the  node’s 
ocn_first_supcls  pointer.  If  the  object  has  a  superclass,  then  tojptr  gets  assigned  to  the 
superclass.  The  pointer  tempi  trails  one  level  below  tojptr  throughout  the  upward 
traversal  of  the  hierarchy.  This  continues  as  long  as  thCTe  remains  a  superclass  to  the  object 
being  visited.  By  definition,  the  top  of  the  hierarchy  contains  no  superclass  so  that  object’s 
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I  Figure  12;  Pointers  for  the  Two  Family  TVees  After  An  Object  Search 
ocii_{irst_supcls  pointer  is  set  to  null.  Because  of  this,  to j)tr  will  also  eventually  be  set  to 
null,  leaving  tempi  pointing  to  the  top-most  node. 

An  identical  upward  travasal  of  the  tree  containing  from_obj  is  then 
accon^lished.  At  the  end  of  the  hierarchy,  temp2  will  also  point  to  the  top-most  object  in 
the  hierarchy.  A  comparison  is  then  made  between  temp  i  and  temp2.  If  they  are  identical, 
then  both  to_obj  and  from.obj  lie  within  the  same  hierarchy  and  a  covering  relationship  is 
not  required.  The  user  is  prompted  as  such  and  asked  to  begin  anew.  If  they  are  not 
identical,  then  it  forms  the  basis  for  a  legitimate  covering  construct  and  the  process 
continues. 

At  this  point,  to_rel_ptr  and  firom_rel_ptr  each  still  point  to  the  objects  defining 
the  relation.  Using  these  pointers,  the  user  is  then  asked  to  confirm  that  he  wants  the 
covering  relationship  to  be  formed  between  the  two  objects.  If  the  answer  is  yes,  then,  using 
the  pointers  to  access  the  nodes,  the  ocn_maiked  variable  is  set  to  true  in  each  of  the  two 
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nodes.  This  prevents  adding  the  objects  to  the  list  of  covered  objects  once  the  hierarchy  is 
traversed.  The  two  variables,  from.obj  and  to_obj,  are  then  sent  to  the  covering  data  file 
and  stored  as  the  second  and  third  item  in  the  list  respectively.  If  the  user  selects  “no”,  then 
he  does  not  wish  to  continue  to  create  the  covering  relation.  In  this  case,  all  pointers  are 
returned  to  null  and  the  covering  menu  is  re-displayed. 


C.  ESTABLISHING  COVERING 

Although  conceptually  a  link  now  exists  between  the  two  hierarchies  in  the  mind  of 

the  user,  in  M^DBMS  no  physical  link  exists.  As  such,  inheritance  is  still  restricted  to  one 
hierarchy.  The  final  process  of  creating  the  covering  relation  involves  determining  the 
scope  of  the  covering  and  accessing  the  relevant  objects  and  establishing  the  physical  links 

for  it  in  MODEMS. 

1.  Determining  the  Scope. 

The  user  is  then  prompted  to  determine  the  scope  of  the  covering  relation.  The 
scope  is  defined  as  the  number  of  levels  in  the  hierarchy  above  and  below  to_obj  which  are 
to  be  encompassed  by  the  covering  relation.  Figure  12  illustrates  the  concept  of  scope.  In 
this  illustration,  the  scope  of  the  covered  object  includes  one  level  above  and  one  level 
below  the  covered  object  The  user  is  first  prompted  for  the  number  of  levels  above  to_obj, 
followed  by  a  prompt  for  the  number  below  to_obj.  Any  number  of  levels,  including  zero, 
can  be  chosen  by  the  user  for  each  entry.  The  system  will  automatically  adjust  for  situations 
where  the  object  is  linked  to  fewer  subclasses  or  superclasses  than  that  specified  in  the 
scope. 

2.  Marking  the  covered  objects. 

The  pointer  toj)tr  is  then  used  to  trav»s6  the  hierarchy  above  to_obj  in 
accordance  with  the  level  specified  by  the  user.  When  the  travCTsal  reaches  either  the  uppo* 
bound  of  the  scope  or  the  last  superclass,  the  pointer  cover_cis  is  set  to  that  node.  The 
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Figure  13:  The  Scope  of  a  Covered  Object 

cover_cls  pointer  is  now  the  starting  point  for  collecting  the  objects  to  be  covered  in  the 
scope. 

3.  Writing  the  data  to  the  data  file. 

The  first  three  items  written  into  the  covering  data  file  are  the  name  of  the 
covering  relation,  to_obj,  and  fromjobj.  The  relation  name  is  taken  firom  the  entry  by  the 
user  when  the  relation  was  named.  The  values  for  from_obJ  and  to_obj  are  determined  by 
accessing  the  attribute  name  of  the  objects  pointed  to  by  from_reI_ptr  and  to_reI_ptr, 
respectively.  Once  these  three  items  are  written  to  the  data  file,  the  covered  objects  can  then 
be  added  to  the  list 
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Beginning  at  the  node  pointed  by  cover  ds,  which  is  still  pointing  to  the  highest 
object  in  the  scope,  the  tree  is  traversed  downward.  The  downward  traversal  continues  until 
the  lower  limit  of  the  scope  is  reached.  Each  node  is  first  checked  for  the  existence  of 
subclasses  that  fall  within  the  scope.  Once  the  subclasses  have  been  checked,  the  search 
moves  to  the  next  node  within  the  same  level. 

As  each  node  that  satisfies  the  scope  conditions  is  visited,  the  variable 
ocn_inarked  is  set  to  true.  This  setting  tags  the  object  for  membership  in  the  covered 
relation  and  the  data  are  then  sent  to  the  data  file.  It  also  prevents  double-counting  when  the 
tree  is  traversed  upward  in  order  to  move  to  a  subclass  of  the  next  object  class.  For  instance, 
the  node  belonging  to  to_obj  is  skipped  because  its  ocn_iiuirked  variable  is  already  set  to 
true.  Once  the  lower  limit  of  the  scope  is  reached,  all  covered  objects  meeting  the  scope 
criteria  have  then  been  written  to  the  data  file.  Following  the  writing  of  data  to  the  data  file, 
the  hierarchy  is  traversed  again  to  reset  all  of  the  ocn_inarked  variables  to  false.  Figure 
14  shows  an  example  data  file.  Compare  this  example  to  the  scope  of  the  covering 
relationship  shown  in  Figure  12. 


FILE:  FAMILY.cover 

IN-LAW  TODD  PAULLA  MIKE  PAUL  ANDY  SAMANTHA 

Figure  14:  Example  of  a  Covering  Data  File 


D.  ACCESSING  THE  DATA  VIA  QUERIES 

Queries  to  die  database  using  the  covering  property  illustrate  the  power  and  flexibility 
of  the  covoing  relationship.  Since  queries  on  the  covering  property  of  one  hierarchy  to  the 
other  involve  these  hierarchies,  it  is  essential  that  the  query  format  be  compatible  with 


34 


object-oriented  queries  already  in  place  in  the  model  for  the  inheritance  property.  With  this 
in  mind,  queries  to  the  database  using  the  covering  property  are  constructed  almost 
identical  to  those  without  the  covering  property. 

The  Object-Oriented  model  on  MDBS  as  implemented  by  Karlider  and  Moore 
[BENV  91]  uses  the  following  format  to  make  queries  on  the  data: 

<object  name>.  retrieve  <attribute  1>,  <attribute  <attribute  n> 

The  object  name  and  the  attributes  in  question  are  specified  by  the  user.  The  query  is 
either  read  from  the  screen  in  this  format  or  stored  with  other  quoies  in  a  request  file  from 
which  the  user  can  choose  queries  from  a  list 

The  following  modification  was  made  to  the  query  format  to  handle  queries  using  the 
covering  property: 

<(from  objectdefining  relation)>  <object>.retrieve  <attribute  <attrjbute  ii> 

Queries  constructed  using  this  format  are  converted  to  the  original  format  before 
processed  in  the  ABDL  transaction.  Each  query  is  intercepted  in  the  KMS  module  where  it 
is  transformed  before  being  sent  to  the  kernel  database  system,  i.e.,  KDS.  Inside  the  KMS 
module,  each  query  is  first  examined  for  format  Queries  involving  covering  are  then 
parsed  and  checked  for  compliance  with  the  covering  relationships  found  in  the  data  rile. 
This  procedure  acts  like  a  filter,  transforming  the  covering  query  into  a  straight  inheritance 
query.  Compliance  with  the  procedure  satisfies  a  boolean  variable,  which  enables  the  query 
to  pass  to  the  KDS  as  if  it  was  a  nornial  inheritance  query.  The  major  difference  is  that  one 
object  outside  the  normal  inheritance  structure  is  now  accessing  objects  in  another 
hierarchy. 


The  transfonnation  process  operates  in  the  foUowing  manner.  Each  query  is  initially 
parsed  to  check  for  parentheses.  The  presence  of  parentheses  signals  a  covering 
relationship  query.  First,  the  defining  relation  found  inside  the  parentheses  is  compared  to 
the  covering  names,  each  of  which  is  the  first  item  in  each  list  found  in  the  covering  data 
file.  If  it  does  not  match  any  of  the  covering  names,  then  the  query  is  rejected  because  no 
covering  relationship  exists  to  satisfy  the  query. 

If  the  defining  covering  matches  a  covering  name,  then  from_object  in  the  query  is 
compared  to  from_obj,  the  second  item  in  each  list  in  the  data  file.  Again,  failure  to  match 
results  in  rejection  of  the  qucy.  However,  if  the  names  do  match,  the  balance  of  the  list  is 
scanned  to  check  for  a  matcn  with  the  query  object  A  successful  match  here  enables  the 
query  to  proceed. 

The  query  sent  to  the  ABDL  translator  is  now  in  the  original  format  equivalent  to  the 
covering  query  minus  the  parenthetical  portion.  From  there,  the  query  is  handled  by  the 
ABDL  translator  in  the  normal  manner.  The  linked  list  of  each  object  is  traversed  searching 
for  a  match.  If  found,  die  attribute  linked  list  of  each  object  is  then  scanned,  matching  the 
query  attributes  with  those  found  in  the  obj«;L  These  objects  and  their  corresponding 
attributes  are  collected  and  compiled  in  the  ABDL  form.  Aftar  the  translated  transaction  has 
been  executed  by  MDBS,  the  file  of  data  satisfying  the  query  is  then  sent  back  to  KMS  for 
conversion  back  to  the  object-oriented  form. 
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V.  ADDITIONAL  MODIFICATIONS  AND  LIMITATIONS  OF  THE 
OBJECT-ORIENTED  INTERFACE 


A  ADDITIONAL  MODIFICATIONS  TO  THE  OBJECT-ORIENTED 

INTERFACE 

In  addition  to  implementing  the  covering  property,  we  incorporated  the  ability  for  the 
object-oriented  interface  to  generate  object-ids.  The  object-id  is  set  up  as  an  attribute  for 
each  object,  and  each  record  within  tfiat  object  requires  a  unique  object-id.  Prior  to 
modification,  the  user  was  required  to  manually  assign  an  object-id  to  each  record.  In 
addition,  on-line  insertions  required  that  the  user  know  in  advance  which  object-ids  had 
already  been  used  in  order  to  avoid  duplication.  In  a  large  database,  this  can  become  a 
problem  if  careful  attention  is  not  paid  to  keeping  track  of  object-ids. 

Our  modification  uses  the  system  clock  to  generate  the  object-id  at  the  time  of  record 
loading.  The  basic  strategy  used  is  to  retrieve  the  Unix  system  time  in  integer  format  and 
convert  it  to  a  string.  Conversion  to  a  string  is  required  because  the  Lil  module  of  the  object- 
oriented  intarface  reads  all  attribute  values  as  strings  from  a  text  file  before  passing  it  on  to 
the  kernel. 

The  advantage  of  using  the  system  clock  is  twofold.  First,  each  record  loaded  is 
essentially  time  stamped,  which  gives  each  record  a  unique  time.  Therefore,  by  definition, 
the  object-id  is  also  unique.  Second,  the  use  of  system  time  allows  records  to  be  clustered 
on  the  data  disk  according  to  their  load  sequence  rather  than  the  value  of  an  attribute  other 
than  die  object-id.  This  is  a  desired  characteristic  for  secure  database  systems  because 
intrusions  into  the  database  do  not  reveal  the  contents  of  a  cluster  data  base  on  its  grouping. 

The  procedure  used  is  called  get_objectid()  and  returns  a  character  string.  It  is  called 
by  the  mssjloadO  procedure  in  the  Lil  directory  of  the  object-oriented  intoface.  Hie  mass 
loading  procedure  is  responsible  for  loading  records  into  the  database.  As  die  mass  load 
procedure  scans  each  line  of  the  record  file,  it  parses  the  first  attribute  of  each  recoid, 
verifying  it  as  the  object-id.  If  the  first  attribute  is  the  object-id,  get_objectidO  is  called  and 


37 


returns  die  new  object-id  for  the  record  being  loaded.  This  in  turn  is  passed  to  the  kernel 
and  stored  in  the  database.  The  object-id  attribute  is  still  maintained  in  the  schema  because 
it  is  an  attribute  of  the  record.  Within  the  record  file,  the  object-id  is  still  used  for  insertion 
as  a  place  holder  to  avoid  confusing  the  system  when  parsing  the  insert  request  However, 
all  the  object-id  values  can  be  the  same  number  because  they  will  be  reassigned  at  load 
time.  The  source  code  for  this  feature  can  be  found  in  Appendix  B. 

Several  implementation  details  arose  in  the  writing  of  this  procedure  which  are 
hardware  and  software  related.  First  Unix  system  time  is  tracked  in  elapsed  seconds 
since  January  1, 1970.  This  time  can  be  accessed  down  to  the  microsecond  level.  In  order 
to  get  a  fine  enough  time  slice  for  the  object-id  assignment  we  needed  to  access  the  system 
time  at  the  microsecond  level.  This  was  necessary  in  order  to  prevent  duplicate  object-id 
assignments  when  loading  records.  Storing  a  number  this  size  would  exceed  the  32-bit 
registers  on  the  current  platform.  Given  a  machine  with  64-bit  registers,  this  problem  would 
be  eliminated. 

In  order  to  work  with  32-bit  registas,  we  modified  the  output  of  the  system  time  into 
an  eight  digit  numba:.  The  number  assigned  to  the  object-id  is  in  the  format  of 
<hhmniss«tt>,  where  bh  is  for  hour  of  the  day  (24  hour  clock),  mm  is  for  minutes  in  the 
hour,  ss  is  seconds  in  the  minute,  and  uu  is  thousands  of  microseconds. 

Unfortunately,  due  to  the  limitations  of  the  time  slice,  testing  revealed  several  cases 
of  duplicate  object-ids.  To  correct  this  problem,  a  delay  loop  was  added  to  the  procedure  to 
delay  assignment  of  the  object-id.  This  resulted  in  zero  duplication  of  object-ids  and  the 
time  delay  is  not  noticed  by  the  user  and  does  not  affect  system  performance.  The  biggest 
drawback  to  this  solution  is  that  non-duplication  of  object-ids  can  only  be  guaranteed  for  a 
session  which  lasts  less  than  24  hours.  However,  since  we  are  not  producing  a  commercial 
database,  and  data  is  not  maintained  in  the  database  beyond  each  session,  this  did  become 
a  problem  during  operation. 

The  second  implementation  issue  is  software  related.  The  current  C  compiler  is  an 
older  version  dated  prior  to  the  ANSI  C  standard.  This  version  contains  no  lilmuy  functions 
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which  convert  an  integer  into  a  character  string.  To  overcome  this  {voblem,  each  digit  of 
the  time  slice  is  fed  into  an  integer  array.  After  lot^g  the  array,  each  field  of  the  array  is 
read  and  a  character  version  of  the  digit  read  is  copied  into  a  corre^nding  character  array. 
Tte  resulting  character  array  is  returned  to  the  mss^kMd  procedure  and  assigned  to  the 
object-id.  The  incurred  overhead  is  not  noticeable  to  the  user  and  can  be  eliminated  when 
the  software  is  ported  to  a  system  with  a  compiler  having  the  required  libraries. 

To  recs^tulate,  die  automatic  assignment  of  object-ids  is  a  vast  improvement  over 
the  method  of  manual  assignment  When  the  software  for  the  object-oriented  interface  is 
ported  to  a  newer,  mart  powerful  system,  the  implementation  drawbacks  discussed  above 
can  be  eliminated. 

B.  LIMITATIONS 

In  addition  to  the  limitations  discussed  in  the  section  above,  tiiere  are  some  significant 
limitations  to  the  object-oriented  in  general  and  covering  in  particular.  The  object-oriented 
intoface  does  not  have  the  capability  to  conduct  on-line  deletion  and  modification  of 
records.  Deletion  and  modification  to  records  must  be  done  off-line  by  editing  the  record 
and  schema  text  files. 

Additionally,  methods  (or  actions),  as  described  in  Chapter  I,  are  not  implemented. 
Inhoitance  of  actions  as  well  as  attributes  is  a  powerful  feature  of  the  object-oriented 
model.  Allowing  user-defined  actions  to  exist  within  an  object  class  is  essential  if  the  full 
benefits  of  the  object-oriented  data  model  (OODM)  ate  to  be  utilized. 

The  object-oriented  interface  carmot  retrieve  a  record  without  specifying  the  unique 
object  class  associated  with  it  This  is  a  major  limitation  of  the  current  syston  because  it 
requires  the  user  to  know  in  advance  which  object  class  contains  the  desired  object  (or 
record).  Ideally,  the  system  should  be  able  to  prcKess  the  following  query: 
retrieve  firstn,  lastn,  salary  if  ssn=  283764958 
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This  query  asks  for  die  first  name,  last  name,  and  salary  for  the  individual  record  widi  the 
social  security  number  2837649S8.  Under  the  current  configuration,  this  query  requires  die 
user  to  specify  a  particular  objea  as  shown  below: 

Joe.retrieve  ffrstn,  lastn,  salary  if  ssns  28376495 

Because  of  this  restriction,  the  current  implementation  requires  the  use  of  object 
classes  with  single  instances  only.  The  end  result  is  that  each  instance  is  actually  an  object 
Unfortunately,  this  prevents  the  covering  property  from  being  fully  utilized.  If  multiple- 
instance  objects  were  possible,  tlMn  covering  could  map  from  one  instance  in  an  object 
class  to  many  instances  of  one  or  more  object  classes. 

Consider  an  object  class  called  STUDENT  and  an  object  class  called  COURSE.  Each 
student  is  enrolled  in  multiple  courses,  while  each  course  contains  multiple  students.  A 
query  to  retrieve  the  course  load  of  student  Jones  requires  a  covoing  relationship  betweoi 
one  instance  of  STUDENT(Jones)  to  many  instances  of  COURSE.  If  a  multiple-instance 
covering  relationship  is  called  ENROLL,  then  die  query  would  appear  as  shown: 

(ENROLL  Jones.  COURSE)  retrieve  coursename 
This  query  will  retrieve  all  courses  enrolled  by  Jones.  Unfortunately,  under  die  present 
system  configuration,  this  query  caruiot  be  performed.  The  best  diat  can  be  achieved  is  to 
make  each  instance  of  STUDENT  and  COURSE  individual  objects.  Then  a  covmng 
relationship  called  ENROLL  must  be  defined  linking  the  object  class  JONES  with  the 
group  of  covered  object  classes. 

Another  limitation  of  the  object-oriented  interface  is  the  inability  to  perform  a  multi¬ 
class  join  with  more  than  two  objects.  The  original  design  of  the  object-oriented  interface 
allows  for  an  attribute  of  one  object  in  an  object  hierarchy  to  point  to  an  object  class  of 
another  object  hierarchy.  In  a  sense,  this  is  covering,  but  it  is  covering  which  is  hard  coded 
at  the  schema  design  level. 

In  order  to  perform  a  join  under  the  original  design,  a  data  structure  called 
okj_tgt_dsl  and  oki_tgt_ds2  [Karl93]  is  used  to  retain  two  values  for  object  names.  The 
purpose  of  these  variables  is  to  store  the  names  of  die  objects  used  in  a  join  for  access 
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during  letrievaL  The  two-object  limitation  discussed  earlier  is  a  result  of  only  diese  two 
variables  being  present  A  possible  solution  to  this  is  to  change  this  data  structure  into  a 
dynamic  one  which  can  grow  with  the  number  of  objects  in  a  join.  However,  the  need  for 
hard  coding  the  relation  between  two  hierarchies  diminishes  because  covering  can  now  be 
done  on  the  fly.  The  idea  of  a  dynamic  data  structure  still  holds  merit  and  will  be  discussed 
further  when  we  review  the  limitations  of  the  covering  property. 

The  covering  implementation  in  the  object-oriented  interface  cannot  be  applied  to 
objects  across  different  databases.  MDBS  allows  for  loading  multiple  databases  in  a  single 
session.  However,  only  one  database  can  be  accessed  at  a  time.  If  the  need  exists  for 
accessing  data  across  different  databases,  the  object-oriented  database  must  be  able  to 
provide  simultaneous  processing  of  databases.  The  covering  construct  would  then  need  the 
name  of  the  desired  database  in  addition  to  the  current  information  normally  needed  to 
access  objects  of  different  hierarchies. 

Another  limitation  of  the  coveting  implementation  is  that  the  covering  construct  can 
only  retrieve  data  from  the  objea  being  covered.  It  catmot  retrieve  data  both  from  the 
covering  object  and  the  covered  object  The  absence  of  this  limitation  would  allow  the 
system  to  perform  joins  by  taking  advantage  of  the  current  data  structure.  However,  as 
discussed  above,  this  join  would  be  limited  to  only  two  objects.  Therefore,  since  one  object 
can  have  multiple  covering  relationships,  the  implementation  of  the  proposed  dynamic  data 
structure  would  be  of  great  benefit 

The  limitations  discussed  above  are  provided  to  inform  the  reader  as  to  what  is  needed 
to  make  the  object-oriented  interface  a  production-ready  database  interface.  However,  our 
work  here  is  to  prove  the  feasibility  of  the  object-oriented  data  model  and  in  particular  the 
irr^lementation  of  the  covering  property.  These  limitations  did  not  interfere  with  our  abiliQr 
to  prove  these  points. 
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VI.  FUTURE  WORK 


There  are  several  issues  for  future  work  which  concern  both  the  object-oriented 
interface  on  MDBS  and  the  covering  property.  While  the  object-oriented  interface  is 
sufficient  for  research  purposes,  it  is  not  ready  for  teal  time  use.  Much  of  the  future  worit 
is  related  to  the  limitations  listed  in  the  Qiapter  V  and  will  be  touched  upon  again  in  diis 
chapter. 

As  discussed  in  Chapter  V,  the  object-oriented  interface  on  MDBS  does  not  have  the 
capability  to  conduct  on-line  updates  and  deletes.  Incorporating  these  operations  into  the 
object-oriented  interface  would  complete  the  model.  In  addition,  this  capability  would  be  a 
significant  step  towards  a  real-time  user  interface. 

Incoiporation  of  methods  (or  actions)  into  the  object-oriented  interface  is  still  needed. 
The  current  model  on  MDBS  allows  only  the  inheritance  of  attributes.  The  addition  of 
methods  to  the  interface  enables  the  user  to  take  full  advantage  of  the  power  of  object- 
oriented  data  model  (OODM).  This  would  allow  CAD/CAM  databases  to  be  implemented 
as  well  as  other  simulation  based  applications. 

While  we  eliminated  the  need  for  the  user  to  supply  and  keep  track  of  object-ids,  the 
user  must  still  name  a  speciflc  object  in  the  query.  This  precludes  the  covering  of  one 
instance  of  an  object  class  to  many  instances  of  another  object  class.  This  limitation  is 
discussed  in  depth  in  (Chapter  V.  Removing  this  limitation  is  required  before  the  full 
benefits  of  covering  can  be  achieved. 

Another  area  for  future  research,  also  discussed  in  Chapter  V,  is  to  remove  the 
limitations  on  two  class  joins.  This  would  signfficantly  expand  and  enhance  the  capability 
of  the  model.  Furthermore,  the  covering  construct  should  be  enhanced  to  allow  for  single 
command  queries  using  multiple  covering  relationships.  In  conjunction  with  this,  the 
ability  to  retrieve  data  via  covering  from  objects  in  other  databases  would  also  make  the 
system  more  robust.  This  requires  simultaneous  proces^g  of  multiple  databases  as  well  as 
safeguards  to  ensure  the  security  and  integrity  accessed  databases  are  maintained. 
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The  cuirent  configuriiion  of  tfie  object-oriented  interface  allows  the  user  to  set  certain 
conditions  for  a  search.  However,  diis  is  limited  to  the  “and”  operation  and  does  not  provide 
for  an  “or”  operation.  The  disjunctive  “or”  is  convenknt  when  searching  for  multiple 
instances  within  the  database.  For  example,  die  following  request  is  presently  allowed  by 
the  object-oriented  interface: 

george.retrieve  firstn,  lastn,  salary  if  salary  <  100000  and  iastn  s  *^mith*’ 

This  quay  requests  the  first  name,  last  name  and  salary  of  all  objects  whose  salary  is  less 
than  100000  and  whose  last  name  is  “Smith”.  If  we  wiriied  to  retrieve  all  records  where 
salary  is  greater  than  1000000  or  whose  last  name  is  “Smith”,  we  would  have  to  retrieve 
the  data  with  two  requests  instead  of  one.  The  proposed  request  would  be  in  the  following 
format: 

george.retrieve  firstn,  Iastn,  salary  if  salary  <  100000  or  Iastn  s  *^niith*’ 

The  current  configuration  of  the  object-oriented  interface  also  lacks  a  text  retrieval 
capability.  This  feature  is  useful  in  many  search  applications.,  such  as  finding  particular 
paragraphs  in  classified  documents.  With  dus  capability,  the  object-oriented  interface 
would  be  an  exceptional  platform  for  maintaining  a  multi-level  security  database. 

Porting  the  source  code  for  the  object-oriented  interface  to  a  programing  language 
such  as  C-H-  or  Ada  would  reap  immense  benefits.  Encapsulation  of  code  using  one  of  these 
languages  improves  the  modularity  and  maitainability  of  the  progrant  By  taking  advantage 
of  the  sophisticated  libraries  in  these  languages,  code  becomes  more  streamlined  and  easier 
to  maintain.  Using  an  object-oriented  programming  language,  such  as  C-H-,  provides 
encapsulation  and  modularity  to  the  program  throughout  the  entire  design  process. 

There  is  also  a  need  for  more  sophisticated  excq)tion  handling  capabilities  in  the 
object-oriented  interface.  Greater  depth  of  error  control  pays  dividends  in  keeping  the 
system  on  line.  Often  times  once  a  mistake  is  made,  it  is  impossible  to  correct  without 
stopping  MDBS,  zeroing  the  processes,  and  restarting  the  system.  One  advantage  to  Ada  is 
that  it  provides  this  simplified  exception  handling  ability  within  its  standard  libraries. 
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The  transition  from  research  product  to  commercial  product  normally  focuses  on 
improvements  that  make  the  product  more  user-friendly.  The  conceptual  design  is  proven, 
but  the  interface  is  weak.  In  view  of  this,  the  issues  discussed  above  are  primarily  provided 
as  suggestions  for  making  the  object-oriented  interface  ready  for  real-time  use. 
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VIL  CONCLUSION 


This  thesis  focused  on  the  implementation  of  the  covering  propmy  of  CX>DM  on 
MDBS.  First,  a  case  was  made  for  the  value  of  the  object  oriented  model  in  goieral.  Unlike 
the  traditional  models  of  database  design,  the  object-oriented  model  avoids  arbitrary 
modeling  while  allowing  greater  abstraction.  At  the  same  time,  OODM  provides  powerful 
constracts,  such  as  inheritance  and  covering,  which  yield  flexibility  and  modularity  not 
available  in  otiier  models.  These  factors  make  OODM  an  ideal  data  model  for  database 
design. 

Second,  the  case  was  made  for  the  use  of  the  federated  database  structure  within  the 
context  of  MDBS.  Federated  databases  allow  greater  local  autonomy  and  provide  the  usa 
with  transparent  access  to  diverse  databases.  The  multimodel/multilingual  system  software 
on  MDBS  is  one  means  to  achieve  rapid  access  to  databases  using  a  variety  of  models  and 
languages.  Using  MDBS  as  the  development  platform  allowed  design  and  implementation 
to  concentrate  on  the  object-oriented  interface  without  having  to  develop  a  new  DBMS 
from  scratch.  Finally,  with  this  background,  the  actual  implementation  of  covering  was 
described  in  detail. 

Covering  required  the  modification  to  the  data  structure  used  in  MDBS  as  well  as  die 
creation  of  a  user-defined  relation  between  the  hierarchies.  Dq>ending  on  the  existing  data 
structure,  changes  to  the  data  structure  may  or  may  not  be  necessary.  In  this  case,  the 
modification  was  necessary,  and  consisted  of  adding  an  additional  pointer  and  a  boolean 
attribute  to  the  object  class  node. 

Before  two  or  more  hierarchies  can  be  linked  together,  a  covering  relation  must  be 
defined.  Without  this  relation,  there  is  no  meaning  to  the  covering  property.  Covering 
singly  becomes  an  arbitrarily  defined  construct  that  has  no  relevance  to  the  database. 
Furthermore,  it  cannot  be  reproduced  systematically  with  meaning  from  one  user  to  the 
next  By  naming  each  covoing  relation,  multiple  coverings  can  be  created  on  the  same 
database. 
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Finally,  the  covering  relationship  must  be  user-defined.  This  accomplishes  two 
objectives.  First,  it  removes  the  notion  of  arbitrariness  from  the  database  and  imposes 
clarity  and  meaning.  A  covering  property  defined  at  the  time  of  database  creation,  is  a  static 
structure,  defined  by  a  programmer  who  may  not  understand  the  needs  or  purposes  of  die 
database.  The  user,  in  contrast,  has  a  specific  need  for  the  covering  relationship  and  has 
qiecific  uses  for  the  information.  Therefore  the  user  is  much  better  suited  to  create  and 
modify  the  covering  property.  Covering  now  becomes  a  dynamic  construct  Second,  the 
scope  of  the  covering  must  also  be  defined  by  the  user.  Incorporating  these  objectives 
allows  the  user  to  tailor  the  database  t'l  his  particular  needs  and  provides  flexibility  and 
clarity  when  forming  queries. 

This  thesis  demonstrated  that  it  is  possible  to  implement  a  covering  relationship  across 
two  hierarchies  within  an  existing  object  oriented  database  structure.  The  actual  product 
is  a  working  database  which  illustrates  the  covering  property.  The  implementation  of 
covering  onto  MDBS  was  accomplished  as  proof  of  viability  of  a  specific  concept  Like  the 
multimodeVmultilingual  software  on  MDBS,  however,  it  is  currently  not  a  working 
program  suitable  for  commercial  use.  With  this  in  mind,  it  is  worth  exploring  alternative 
applications  of  the  covering  property  beyond  the  family  tree  analogy. 

A.  COVERING  APPLICATION  ONE:  A  NAVAL  TASK  FORCE 

A  realistic  application  of  the  covering  property  within  a  military  context  is  the 
creation  of  a  task  force.  The  task  force  structure,  in  widespread  use  within  the  U.S.  Navy, 
has  applications  to  the  Navy  as  well  as  other  services.  Furthermore,  the  inherent 
hierarchical  structure  of  particular  classes  of  ships  makes  it  not  only  an  ideal  example,  but 
also  an  appropriate  and  applicable  use  for  the  covering  property. 

Carrier  battle  groups  are  normally  composed  of  twelve  ships,  with  the  aircraft  carrier 
serving  as  the  flagship  and  centerpiece  of  the  task  force.  Each  ship  within  the  task  group 
serves  a  specific  purpose  and  each  brings  their  unique  strengths  and  abilities  to  the  battle 
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group.  Yet,  when  the  task  force  is  constructed,  each  particular  ship  is  drawn  from  their  own 
respective  classes  and  not  from  a  task  group  hierarchy.  In  other  words,  the  task  group  is 
created  from  existing  ship  hierarchies. 

For  example,  the  carrier  is  drawn  from  the  object  class  CARRIER,  which  is  further 
divided  into  the  object  classes  CONVENTIONAL  and  NUCLEAR.  Within  each  of  these 
object  classes  are  specific  classes  of  carriers:  the  NIMITZ,  KENNEDY,  or  ENTERPRISE 
nuclear  carriers  and  the  KITTY  HAWK,  FORREKTAL,  or  RANGER  conventional  carriers. 
Each  of  these  object  classes  contains  the  specific  ship  objects  for  their  respective  class. 
Similarly,  each  cruiser,  destroyer,  and  frigate  chosen  for  the  task  force  comes  from  their 
own  respective  class  hierarchies.  An  example  of  the  CARRIER  object  class  is  illustrated  in 
Figure  15. 

The  task  force  is  essentially  a  collection  of  ships  drawn  from  unrelated  hierarchies. 
Thus,  the  creation  of  a  task  force  is  actuaUy  the  creation  of  a  specific  covering  construct. 
For  example.  Battle  Group  Bravo,  as  defined  by  higher  authority,  might  consist  of  the 
following  ships: 

CARRIER:  CVN-72 

CRUISERS:  CG  •  52 

DESTROYERS:  DD  -  963,  DD  -  982,  DD  -  983 

FRIGATES:  FEG  -  7 

Battle  Group  Bravo,  as  defined  by  the  Battle  Group  Commander,  is  the  covering 
property  that  links  the  various  hierarchies  together.  The  scope  of  the  covoing  is  defined 
when  the  admiral  chooses  the  ships  that  will  make  up  the  task  force.  The  creation  of  Battle 
Group  Bravo  from  the  various  ship  hierarchies  is  illustrated  in  Figure  16. 

Prior  to  the  creation  of  the  task  force,  each  object  in  its  respective  class  hierarchy  is 
able  to  access  data  on  any  object  in  the  same  hierarchy  through  the  use  of  the  inheritance 
property.  For  example,  the  phalanx  anti-missile  gun  mount  is  found  on  every  aircraft 
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CARRIERS 


Figure  15:  Example  of  the  object>ciass  CARRIER  and  its  component _ 

carrier.  If  parts  or  ammunition  for  the  phalanx  are  required,  the  carrier  hio'archy  could  be 
searched  using  inheritance  to  find  spare  parts  among  the  other  carriers.  However,  the 
phalanx  is  found  on  other  ships  as  well.  Without  covoing,  the  parts  inventories  of  the  other 
ships  could  not  be  accessed  from  the  carrier.  This  is  because  inheritance  does  not  cross 
hierarchies.  Since  the  parts  inventory  can  be  accessed  through  the  inheritance  hierarchy  of 
each  object  class,  accessing  the  hierarchy  via  covraing  allows  access  to  the  respective 
inventories. 
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CRUISER 


Figure  16:  Establishing  a  Ihsk  Force  using  the  Covering  Construct  BATTLE  GROUP  BRAVO 


B.  COVERING  APPLICATION  TWO:  MULTI-LEVEL  SECURITY 

A  second  application  involves  the  access  requirements  of  multi-level  security 
arrangements  normally  found  in  the  military  environment  OODM  is  ideal  for  supporting 
the  multi-level  security  policy  and  its  associated  access  control  requirements  [Hsia91b]. 
This  is  because  OODM  properties  of  inheritance  and  covering  provide  the  necessary 
mechanisms  to  preserve  security  constraints  while  still  allowing  access  to  the  data. 

All  documents  within  the  military  are  classified  according  to  four  primary  security 
classifications.  These  classifications,  listed  from  lowest  to  highest  classification,  are 
UNCLASSIFIED,  CONFIDENTIAL,  SECRET,  and  TOP  SECRET.  As  the  name  impUes, 
thae  are  no  restrictions  to  unclassified  documents.  However,  in  order  to  access  information 
in  documents  other  than  unclassified,  two  conditions  must  be  satisfied. 

One,  the  person  must  possess  a  personal  clearance  level  equal  to  or  higher  than  the 
clearance  classification  of  the  document.  For  example,  a  secret  clearance  satisfies  this 
requirement  for  secret  and  confidential  documents.  Two,  the  person  must  have  a  need-to- 
know  the  information.  Both  conditions  must  be  met  before  access  can  be  granted.  This  is 
known  as  compartmentalizaiion.  Thaefore,  simply  possessing  a  secret  clearance  does  not 
entitle  a  person  access  to  any  secret  or  confidential  document  Togetho’,  the  clearance 
level  and  the  need-to-know  policies  gov^  access  to  classified  information. 

OODM,  using  inheritance,  naturally  supports  the  need-to-know  policy  and  access 
control  requirements  for  unclassified  data  [Hsia91b].  Within  the  object-class  hierarchy, 
there  exists  an  owner/subclass  relationship  at  each  level.  Attributes  and  methods  (or 
actions)  are  passed  down  to  subclasses  via  the  inheritance  property.  Restrictions  on  access 
to  data,  namely  the  need-to-know  policy,  are  manifested  in  the  attributes  and  actions  that 
are  passed  to  the  subclass.  This  is  analogous  to  the  notion  of  the  view  in  the  relational 
model,  where  the  system  filters  the  data  to  the  user  according  to  the  parameters  defined  by 
the  owner.  The  advantage  of  OODM  is  that  it  avoids  the  “triggering  mechanism"  used  to 
maintain  data  integrity  in  other  models. 
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While  inheritance  will  suffice  for  meeting  the  access  control  requirements  for 
unclassified  data,  it  is  insufficient  for  classified  data.  This  is  due  to  the  ‘‘read  down/write 
up”  operations  required  in  the  multi-level  security  policy: 

The  read-down  operation  allows  a  user  of  the  classified  database  to  read  all  the 
data  whose  classifications  are  either  below  or  identical  to  die  clearance  of  the  user. 
The  write-up  operation  allows  a  user  of  classified  data  to  write  into  the  database  a 
piece  of  classified  data  whose  classification  is  either  above  or  identical  to  the 
clearance  of  the  user  [Hsia91c]. 

The  read  down  operation  may  be  thought  of  as  mapping  a  cleared  user  to  classified 
data.  Consider  an  object,  called  USER,  with  an  attribute  CLEARANCE  LEVEL.  A  user 
with  a  top-secret  clearance  level  maps  to  all  documents  classified  top-secret,  secret  and 
confidential  and  unclassified;  a  secret  user  maps  to  all  documents  classified  secret, 
confidential  and  unclassified;  a  confidential  user  maps  only  to  those  documents 
confidential  or  unclassified.  Figure  17  illustrates  this  concept  [Hsia91c]. 

Similarly,  a  write-up  covering  maps  cleared  users  for  writing  data  into  classified 
documents.  However,  because  of  the  nature  of  the  write-up  policy,  the  higher  the  clearance 
level  of  the  user,  the  narrower  the  mapping  of  the  write-up  operation.  This  peculiarity  is  due 
to  the  intent  behind  the  write-up  operation.  Tlie  write-up  operation  is  constructed  so  that 
high  clearance  users  are  not  wasting  time  inserting  data  into  databases  at  a  lower 
classification  than  their  own.  It  is  important  to  note  that  the  write  operation  allows  the  user 
to  insert  data  into  the  data  base,  not  write-over  existing  data.  The  write-up  covmng  is 
illustrated  in  Figure  18  [Hsia91c]. 

Once  the  covering  operation  is  defined  (either  read-down  or  write-up),  die  scope  of 
the  covering  determines  the  structure  of  the  read-down  hierarchy  or  write-up  Merarcky. 
The  method  that  will  perform  eidier  the  read-down  or  write-up  operations  will  be  contained 
in  the  object  CLASSIFIED  DATA.  However,  the  read-down  method  can  only  be 
p^ormed  in  the  read-down  hierarchy,  while  the  write-up  method  can  only  be  performed 
in  die  write-up  hierarchy.  The  methods  operating  within  the  defined  covering  hierarchies 
establish  the  access  control  requirements  for  the  multi-level  security  policy. 
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An  user  profile  with  top'Secret  clearance 


{subsets  of  classified  documents 
with  the  top-secret  classification} 

{ subsets  of  classified  documents 
with  the  secret  classification} 

subsets  of  classified  documents 
with  die  confidential  classification} 

{ subsets  of  classified  documents 
with  the  unclassified  classification} 


An  user  profile  with  secret  clearance 


An  user  profile  with  confidential  clearance 


(subsets  of  classified  documents 
with  the  secret  classification} 

(subsets  of  classified  documents 
with  the  confidential  classification} 

(subsets  of  classified  documents 
with  the  unclassified  classification} 


(subsets  of  classified  documents 
with  die  confidential  classification} 

(subsets  of  classified  documents 
with  die  unclassified  classification} 


An  user  profile  with  unclassified  clearance - ►(subsets  of  classified  documoits 

with  the  unclassified  classification} 


Figure  17:  Uang  covering  to  map  the  ^‘Read-Down**  principle 
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An  user  profile  with  top-secret  clearance - ►{subsets  of  classified  documents 

with  the  top-secret  classification) 


An  user  profile  widi  secret  clearance 


An  user  profile  with  secret  clearance 


{subsets  of  classified  documoits 
with  the  top-secret  classification) 

{ subsets  of  classified  docummts 
with  the  secret  classification) 


{subsets  of  classified  documents 
with  the  top-secret  classification) 

{subsets  of  classified  documents 
with  the  secret  classification) 


{subsets  of  classified  documents 
with  the  confidential  classification) 


An  user  profile  with  top-secret  clearance 


{subsets  of  classified  documents 
with  the  top-secret  classification) 

{subsets  of  classified  documents 
with  the  secret  classification) 

{subsets  of  classified  documents 
with  the  confidential  classification) 

{subsets  of  classified  documents 
with  the  unclassified  classification) 


Figure  18:  Using  covering  to  map  the  *^rite-Up*’  principle 
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C.  SUMMARY 


In  conclusion,  we  have  shown  the  utility  and  benefits  of  using  covering  as  a  means  of 
enhancing  OODM.  CX)DM  provides  unique  modeling  capabilities  which  can  be  directly 
transfened  into  implementation.  It  has  been  shown  that  inheritance  is  a  necessary  but  not  a 
sufficient  property  for  the  OODM.  Covering  allows  access  between  inheritance  hierarchies 
within  an  object-oriented  database.  Without  covering,  access  to  objects  is  limited  within  the 
hierarchy  of  that  object  Together,  inheritance  and  covering  meet  die  necessary  and 
sufficient  conditions  to  make  the  OODM  a  complete  data  model. 
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Figure  20:  The  Object-Attrilnite  Node  Data  Structure 
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Figure  22:  The  Object>Subclass  Node  Data  Structure 
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APPENDIX  B.  SOURCE  CODE 


A.  SOURCE  CODE  FOR  THE  CREATION  OF  A  COVERING  RELATION 

I* 

*  SHcadcn  ojcovcr.c,v  0.0  93A)8/31  15:10  mdbs  Exp  $ 

*  SSouice:  /^A»ibsAicVC^^Rl/^/limgIF/snVObj/LU/o_cove^.c,v  $ 

*  $Log:  o_covcr.c,v  $ 

*  Revision  0.0  93A)8/31  15:10  mdbs 

*  creation 

*  Revision  1.0  93/08/31  20:55  mdbs 

*  modified  for  INSERT  statement  accomplishment 

* 

*  This  file  contains  the  source  code  for  the  implementation  of  the  covering 

*  property.  Its  main  purpose  is  to  allow  the  user  to  define  a  covoing  relation 

*  by  naming  it  and  defining  it  in  terms  of  end  points  of  the  relation  and  the 

*  scope  of  covering.  This  file  also  includes  procedures  which  di^lay  the 

*  covering  choice  menu,  allow  the  displaying  of  existing  covering  constructs, 

*  and  displaying  objects  available  for  the  construction  of  a  covering  constnict 

*  Source  code  for  using  the  covering  constructs  in  tiie  retieval  of  data  can  be 

*  found  in  tiie  file  obj_parser.c  located  in  the  Kms  directory. 

*/ 

#include  <stdio.h> 

#include  <licommdata.h> 

#include  <ool.h> 

#include  <ool_lildcl.h> 

#include  "flags.def ' 
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I*  This  procedure  displays  die  covering  menu  which  allows  for  the  display  or 

*  construction  of  covering  relations  and  di^lay  the  objects  available  for 

*  covering. 

*/ 

o_cover_menuO 

{ 

char  choice; 
int  num; 

int  stop;  /*Boolean*/ 

#ifdef  EnExFlag 
printfC'Enter  o_cover_menu\n"); 
fflush(stdout); 

#endif 

systemC’clear");  /*aear  screen*/ 

ool_info_ptr  =  &(cuser_obj_ptr->ui_li_type.li_ool); 

stop  =  FALSE; 

while  (stop  *=  FALSE) 

{ 

printf("\nEnter  type  of  operation  desiredVn"); 

printf("St(d)  -  Display  Existing  Covering  (ZonstructsNn”); 

printf("\t(c)  -  Display  Available  aassesNn"); 

printf("\t(e)  -  Establish  a  Covering  Construct  Between  Two  ObjectsVi"); 

printf("Vt(x)  -  Return  to  previous  menuNn"); 

ool_info_ptr->oi_answer  =  get_ans(&num); 

switch  (ool_info_ptr->oi_answer) 

{ 

case 'd' :  /*View  existing  covering  construct*/ 
o_read_cover_fileO; 
break; 

case  'c' :  /*View  existing  objects  in  current  database*/ 
o_display_classesO; 
break; 

case  'e' :  /*Establish  covering  relation  betwen  two  objects*/ 
o_get_objcctsO; 
break; 

case  'x' :  /*Exit  menu*/ 
stop  =  TRUE; 
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break; 

default :  /*Incorrect  choice*/ 

printf(”\nEiTor  -  invalid  operation  selectedVn"); 
printfC'Please  select  a  valid  operation.Vn"); 
tveak; 

}  /*End  switch*/ 

}  /*End  whilc(stop=FALSE)*/ 

systemC'clear");  /*Clear  screen*/ 

/*Retum  to  previous  menu*/ 

#ifdefEnExFlag 
printfC’Exit  o_cover_mcnu\n''); 
fflush(stdout); 

#cndif 

}  /*End  o_cover_menu()  */ 
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/*This  procedure  checks  for  existing  covering  constructs.  C^ns  and  reads 
"<dbname>.cover"*/ 
ojread_covcr_fileO 
{ 

char  covcr_filc[FNLcngdi  +  3]; 

struct  obj_dbid_nodc  *dbjptr, 

FILE  *fid; 

db_ptr  =  cuser_obj_ptr->uLli_typc.li_ooLoi_curr_db.cdi_db.dn_obj; 
strcpy(covcr_file,  db_ptr->odn_naine); 
strcat(cover_file,  ".cover"); 
fid  =  fbpcn(cover_file,  "r"); 

if  (fid  ~  NULL)  /*No  covering  files  exist  for  current  database*/ 

{ 

printf("\nNo  covering  constructs  exists  for  this  databaseSn"); 

} 

else  /*Covering  file  found  for  current  database*/ 

{ 

o_read_cover(fid);  /*Read  covering  file*/ 
fclose(fid); 

} 

}  /*End  o_jead_cover_fileO*/ 
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/*  This  proceduie  reads  the  openned  covering  file  and  displays  its  contents  to 
♦the  user. 

*/ 

o_read_covcr(fid) 

FILE  *fid; 

{ 

char  nanie[21]; 

int  com  =  TRUE;  /*BOOLEAN*/ 
int  in_char, 

while  ((in_char  =  getc(fid))  !=  EOF)  /* While  not  End  of  file*/ 

{ 

if  (in_char  !=  ’@@')  /*  scpcratcs  records.  Looking  for  end  of  record.*/ 

{ 

printf("\n"); 

putchar(in_char); 

fscanf(fid,  "%s",  name);  /*Gcts  name  of  covering  construct*/ 
printf("%-6s : ",  name); 

fscanf(fid,  "%s",  name);  /*Gets  covering  object*/ 
printf("%-4s  covers  ",  name); 
fscanf(fid,  "%s",  name);  /*Gets  covered  objects*/ 
printf("%-4s  and  includes  the  object(s):  ",  name); 

} 

while(cont)  /*Get  rest  of  objects  in  scope  of  covering  relationship*/ 

{ 

fscanf(fid,  "%s",  name); 
if  (strcmp(name,  "@@")) 

{ 

printf("%s  ",  name); 

) 

else 

{ 

cont  =  FALSE; 
fscanf(fid,  "\n"); 

) 

}  /*End  while(cont)*/ 
cont  =  TRUE; 

)  /*End  while*/ 
printf("Vn"); 

}  /*End  o_read_coverO*/ 
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Provides  the  user  with  a  list  of  objects  available  for  creating  a  cov«ing 
construct  This  is  accomplished  by  pointing  to  the  first  object  of  die 

*  database  and  writing  the  name  of  the  object  to  the  file  "cova-"  and  then 

*  moving  to  the  next  object  in  the  list  Once  the  list  has  been  traveresed,  the 

*  file  is  closed  and  then  displayed  to  the  screen.  The  file  is  deleted  upon 

*  exiting  the  procedure. 

*/ 

o_display_classesO 

{ 

struct  obj_dbid_node  *db_ptr; 
struct  ocls_node  *cls_ptr; 
struct  o_supcls_nodc  *supcls_ptr; 
struct  o_subcIs_nodc  *subcls_ptn 
struct  oattr_node  *attr_ptr, 

FILE  ♦fid; 

/♦Point  to  first  object  of  current  database.  ♦/ 

db_ptr  =  cuser_obj_ptr->ui_li_typc.li_ool.oi_curr_db.cdi_db.dn_obj; 

fid  =  fopen(''cover","w"); 

iprintf(fid,"Database  Name  :  %s\n",db_ptr->odn_name);/*'Print  name  of  database^/ 

/♦Traverse  list  and  write  object  names  to  the  recieving  fUc*/ 
cls_ptr  =  db_ptr->odn_first_cls; 
while  (els  ptr) 

{ 

fprintf(fid, "CLASS  %s\n",  cls_ptr->ocn_name); 
cls_ptr  =  cls_ptr->ocn_next_cls; 

} 

fclose(fid); 

systemC'morc  cover");  /*Display  list  of  objects.*/ 
systemC’rm  cover");  /♦Delete  file*/ 

}  /♦End  o_display_classesO*/ 
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I*  This  procedure  allows  the  user  to  define  a  covering  relationship.  It  recieves 

*  as  input  the  name  of  the  covmng  relation  desired,  the  name  of  the  covering 

*  object  and  the  name  of  the  covered  object  A  search  is  conducted  to  verify  that 

*  the  objects  exist  in  the  current  database.  If  bodi  objects  exist,  then  a  check 

*  is  made  to  verify  that  both  objects  are  not  in  the  same  inheritance  hierarchy. 

*  If  they  are,  the  request  is  rejected.  If  the  two  objects  are  in  seperate 

*  hierarchies,  then  the  procedure  continues  and  die  user  is  pronqited  for  the 

*  scope  of  the  covering  relation.  Once  the  scope  is  defined,  a  procedure  is 

*  called  to  find  the  objects  with  in  the  scope  of  the  covering  and  writes  them 

*  to  the  covering  file  for  that  database. 

*/ 

o_get_objectsO 

{ 

struct  obj_dbid_nodc  *db_jptr; 
stroct  ocls_node  *cls_ptr, 
struct  o_supcls_node  *supcls_ptr, 
struct  ocls_node  *from_ptr, 

♦to_ptr, 

♦fTom_rcl_ptr, 

*to_relj)tr, 

♦tempi, 

♦cover_ptr, 

♦tcmp2; 
char  choice; 

char  from_obj[l  1]; 

char  to_obj[ll]; 

char  covcr_namc[211;  /*Name  of  covering  construct*/ 

int  found  =  FALSE;  /*Boolean*/ 

int  counter  =  0; 

int  u_limit  =  0;  /*Upper  limit  for  covering*/ 

int  Llimit  =  0;  /*Lower  limit  for  covoring*/ 

int  num; 

#ifdef  EnExFlag 
printfC'Enter  o_get_objects'n"); 
fflush(stdout); 

#endif 


/♦point  to  current  database*/ 

db_ptr  =  cuser_obj_ptr->ui_li_type.li_ool.oi_curr_db.cdi_db.dn_obj; 
cls_ptr  =  db_ptr->odn_first_cls;  /*point  to  first  in  database.*/ 
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/*Get  desired  object  names  and  name  covering  construct*/ 
piintfCSnEnter  the  name  of  the  covering  construct  you  wish  to  createNn"); 
printfC'Use  all  CAPITAL  letters  when  entering  name.\n"); 
scanf(”%s",  cover_name); 

ptintf(”VnEnter  the  luime  of  the  object  you  wish  to  cover  FROM.\n"); 
inintfC'Use  aU  CAPITAL  letters  when  entering  name.'^*'); 
scanf("%s",  frorrt_obj); 

ptintf("\nEnter  the  name  of  the  object  you  wish  to  cover  TO.Nn"); 
printfC'Use  ail  CAPITAL  letters  when  entering  name.\n"); 
scanf("%s",  to_obj); 

/♦Search  for  objects*/ 
while  (Ifound  &&  cls_ptr) 

{ 

if  ((strcmp(cls_ptr->ocn_name,  from  obj))  =  0) 

{ 

found  =  TRUE;  /*Object  found*/ 

from_ptr  =  cls_ptr, 

} 

else 

{ 

cls_ptr  =  cls_ptr->ocn_next_cls; 

)  /"End  if(strcmpO*/ 

}  /"End  while(not_found)*/ 

if  (ifound) 

{ 

printf("Vn%s",  fTom_obj); 
printfC  does  not  exisL'«"); 

} 

else 

{ 

found  =  FALSE; 

cls_ptr  =  db_ptr->odn_first_cls; 

while  (ifound  &&  cls_ptr) 

{ 

if  ((strcmp(cls_ptr->ocn_name,  to_obj))  —  0) 

{ 

to_ptr  =  cls_ptr, 
cover_ptr  *  to_ptr; 

found  =  TRUE;  /*Sccond  object  found*/ 

} 

else 
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{ 

cls_ptr  *  cls_4)tr->ocii_ncxt_cls; 

}  /•End  if(strcmpO)*/ 

}  /*End  whilc(noi;_found)*/ 

if  (Ifound) 

{ 

IHintf("Vn%s",  to_obj); 
printfC*  does  not  existNn"); 

} 

else 

{ 

firom_rel_ptr  =  from_ptr,  /•Marks  "from  object"  for  relationship  reference*/ 
to_rel_ptr  =  to_ptr,  /*Marks  "to  object"  for  relationship  reference*/ 

/•Check  to  see  if  objects  are  in  same  hierarchy*/ 
while(to_j)tr) 

{ 

tempi  =  to_ptr, 

to_ptr  =  to_ptr->ocn_first_supcls->osn_supcls; 

}  /•End  while(to_obj)*/ 
while(front_ptr) 

{ 

temp2  =  from_ptr, 

from_ptr  =  from_ptr->ocn_first  supcls->osn  supcls; 

} 

if(templ  !=  temp2) 

{ 

printfCVnA  covering  relation  is  being  created  from  "); 

printf("%s",  from_obj); 

printf("  to  "); 

printf("%s",  to_obj); 

printf("VnIs  this  correct  (y  or  n)?  "); 

scanf("  %c",  &choice); 

switch  (choice) 

{ 

case  y :  /*User  accepts  covering  construct*/ 

{ 

/•Determine  number  of  levels  above  and  below  to  object  in  the 


67 


hierarchy  which  will  be  included  in  the  covering  construct*/ 
piintfC'NnHow  many  levels  above  %s  should  the  covering  construct  include?  ", 
to_rel_ptr->ocn_name); 
scanf("  %d",  &u_liinit); 

printf(”VnHow  many  levels  below  %s  ^ould  the  covering  construct  include?  ", 
to_rel_ptr->ocn_name); 
scanf("  %d",  &l_limit); 
counter  =  LUmit  +  u_limit; 

/*Check  and  adjust  counter  for  lower  limit  of  hierarchy  incase  the 
*lower  limit  exceeds  the  depth  of  the  hierarchy. 

*/ 

to_ptr  =  to_rel_ptr, 

while  (0_limit  >  0)  &&  to_ptr->ocn_first_subcls->osn_subcls) 

{ 

to_ptr  =  to_ptr->ocn_first_subcls->osn_subcls; 

Llimit-; 

1 

counter  *=  coimter  -  Llimit; 

/*Mark  top  object  in  covered  part  of  hierarchy.*/ 
while((u_limit  >  0)  &&  cover_ptr->ocn_first_supcls->osn_supcls) 

{ 

coverjptr  ®  cover_ptr->ocn_first_supcls->osn_supcls; 
ujimit-; 

}  /*End  whilc(u_limit); 

counter  =  counter  -  u.limit;  /*  Adjusted  counter  for  hiaarchy  size*/ 
if  (cover  j)tr) 

{ 

from_rel_ptr->cover_cls  =  cover_ptr; 

} 

else 

{ 

fromj:el_ptr->covcr_cls  =  tempi; 
cover_ptr  =  tempi; 

}  /*End  if(cover)*/ 

/♦Places  objects  of  covering  construct  into  file*/ 
o_cover_filc(cover_ptr,  to_rel_ptr,  from_rel_ptr,  counter,  cover_name); 
printf(”VnThe  covering  construct  has  been  complet6d.\n"); 
break; 

) 
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case  'll' :  /*User  does  not  accept  the  covering  construct*/ 

{ 

printf("VnThe  covering  construct  has  been  deleted.Nn"); 
tseak; 

) 

default : 

{ 

piintfCVnlnvalid  selection.  Start  again.^"); 

} 

}  /*End  switch(choice)*/ 

) 

else 

{ 

printf(”\n9bs",  from_obj); 
printfC  and "); 
printf("%s",  to_obj); 

printfC  belong  to  Ae  same  inheritance  hinaichy.Nn"); 

printfC  A  covering  construct  is  not  needed  for  these  two  objects.Nn"); 

}  /*Endif(templ  !=  tempi)*/ 

}  /*Endif(!found)*/ 

}  /*End  if(not_found)*/ 

#ifdef  EnExFlag 
printfC'Exit  o_get_objects\n"); 
fflush(stdout); 
fflush(stdin); 

#endif 

)  /♦End  0 _get_objects()*/ 
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/*  This  procedure  travo’ses  the  hierarchy  of  the  covered  objea  and  writes 

*  to  the  covering  file  die  objects  which  fall  within  the  scope  of  the 

*  covering  construct 

*/ 

o_cover_file(cover_ptr,  to_rel_ptr,  firom_rcl_ptr,  counter,  cover_name) 
struct  ocls_node  *to_rcl_ptr, 

*firorn_rel_ptr, 

♦covcr_ptr, 
int  counter, 

char  cover_name[21]; 

( 

char  cover_filc[FNLcngth  +  3]; 

FILE  *fid; 

struct  obj_dbid_nodc  *dbasc_ptr; 

struct  ocls.node  *tcinp_ptr, 

struct  o_subcls_node  *follow; 

int  max  =  0; 

int  leave  =  TRUE; 

int  stait_up  =  TRUE;  /^Allows  counter  to  get  into  initial 

loop  at  a  max  value.*/ 


tcmp_ptr  =  covcr_ptr, 

dbase_ptr  «  cuser_obj_ptr->ui_li_type.li_ool.oi_cuiT_db.cdLdb.dn_obj; 
strcpy(cover_filc,  dbasc_ptr->odn_name);  /*Gets  name  of  database*/ 
strcat(cover_file,  ".cover");  /*Gcats  name  of  covering  file*/ 

fid  =  fopcn(cover_file,  "a"); 

fyrintf(fid,  "%s  ",  cover_name);  /*Name  of  covering  construct  inserted*/ 
fpiintfCfid,  "%s  ",  from_rcl_ptr->ocn_name);  /*From  object  inserted*/ 
i^rintf(fid,  "%s  ",  to_rel_ptr->ocn_name);  /*To  object  insoted  next  in  line*/ 
fiom_rcl_ptr->ocn_markcd  =  TRUE; 
to_rel_ptr->ocn_marked  =  TRUE; 
max  =  counter; 

/*The  following  code  traverses  the  covered  hierarchy  and  retrieves  the  names 
*of  the  include  objects.  As  each  node  is  traversed,  the  "ocn_marked"  bit  is 
*set  to  signify  that  the  node  has  already  been  searched  and  prevents  another 
*retrieval.  The  counter  keeps  track  of  how  many  levels  have  been  traversed 
*so  as  not  to  exceed  the  setting  for  the  covering  construct 
*/ 

if  (!temp_ptr->ocn_marked) 

{ 
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fprintf(fid,  "%s  ",  teinp_ptr->ocn_nainc); 

} 

follow  *»  tcmp_pir->ocn_first_subcls; 
tm^_ptr->ocn_inaiked  =  TRUE;  /*Marks  object  as  visited*/ 
ten^_ptr  =  tcinp_ptr->ocn_first_subcls->osn_subcls; 

while  (((counter  <  max)  II  start_up)  &&  (max  !»  0)) 

{ 

start_up  s  FALSE; 

while(counter  1=0  &&  temp_ptr  &&  leave) 

{ 

if  (!tcmp_ptr->ocn_markcd) 

( 

^printf(fid,  "%s  ",  tcmp_ptr->ocn_name); 
teiT5)_ptr->ocn_marked  =  TRUE; 
tcmp_ptr  =  temp_ptr->ocn_first_subcls->osn_subcls; 
if  (temp_ptr) 

{ 

follow  *  tcmp_ptr->ocn_first  supcls->osn_supclS'>ocn_first_subcls; 

1 

counter-; 

} 

else  if  (temp_ptr->ocn_first_subcls->osn_subcls) 

{ 

icn^_ptr  =  temp _ptr->ocn_first_subcls->osn_subcls; 
if  (temp_ptr) 

{ 

follow  =  temp _ptr->ocn_first_supcls->osn_supcls->ocn_first_subcls; 

} 

counter—; 

} 

else 

{ 

leave  =  FALSE; 

}  /*End  if(!temp_ptr->ocn_marked)*/ 

}  /*End  whileQ*/ 

if  (follow->osn_ncxt_subcls) 

{ 

follow  =  follow->osn_next_subcls; 
temp_ptr  =  follow->osn_subcls; 
countcr++; 
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stariLup  =  TRUE; 

) 

else 

{ 

if(follow->osn_subcls) 

{ 

follow  *  foIIow->osn_subcls->ocn_first_supcIs->osn_supcls-> 
ocn_first_supcls->osn_supcls->ocn_first_subcls; 
*ciTq?_J)tr  =  follow->osn_subcls; 

} 

counter  ==  counter  -f  2; 

}  /*Endif(foUow)*/ 
leave  *  TRUE; 

}  /*End  while(counter  <=  max)*/ 


fprintfCfid,  •'Sn@@Nn"); 
fclose(fid); 

/♦Qear  marked  bits  in  covered  hierarchy*/ 
tempj)tr  =  dbase_ptr->odn_first_cls; 
while  (temp_ptr) 

{ 

tcmp_ptr->ocn_marked  =  FALSE; 
temp_ptr  *=  temp_ptr->ocn_next_cls; 

} 


}  /*End  o_covcr_fileO*/ 
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B.  SOURCE  CODE  FOR  QUERYING  VU  THE  COVERING  CONSTRUCT 
/* 

*  SHcadcr  obj_|>arscr.c,v  0.0  92/1 1/29  13:53  ksh  Exp  $ 

*  SSouice:  /u/mdbs/rich/CNTRL/n/LangIF/src/Obj/Kins/obj_parser.c,v  $ 

*  $Log:  obj_parser.c,v  $ 

♦Revision  0.0  92/1 1/29  13:53  ksh 

♦creation 

* 

♦/ 

#include  <stdio.h> 

#include  <string.h> 

#include  <licoinmdata.h> 

#include  <ool.h> 

#include  <ool_lildcl.h> 

#include  ''flags.def ' 


parse_ool_requestO 

{ 

char  ♦ool_req, 

♦new_ooLreq,  /♦Added  to  implement  covering. 

Replaced  ♦ool_req  after  assignment^/ 
temp_str[InputCols], 
cover_temp[InputCols], 
condition_str[InputCols], 

♦check_coverO; 
int  i, 

in_char, 

covered, 

qualified.attr  =  FALSE; 
strua  obj_kms_info  ♦kms_ptr, 

♦obj_kms_info_alloc(); 
struct  ocls.node  ♦requested_class, 

♦find_classO; 

FILE  ♦temp_file; 


#ifdefEnExFlag 

printfC'Enter  parse_ool_requesf«i"); 
#endif 
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f*  allocate  and  initialize  first  obj_knis_info  struct  */ 
kinsj»tr  =  obj_kms_info_allocO; 
ool_info_ptr->oi_kim_data.ki_o_kins  =  knis_ptr; 
knis_ptr->oki_ncxt  =  NULL; 
strcpy(kins_ptr->oki_tgt_clsl.tci_nanie,  BLANK); 

strcpy(lans_ptr->oki_tgt_clsl.conimon_attr,  "OBJECTID");  /*  default  common  attr  ♦/ 
lans_ptr->oki_tgt_clsLlci_tgt_attrs  =  NULL; 
kmsj>tr->old_tgt_clsl.tci_conditions  =  NULL; 
strcpy(kms_ptr->oki_tgt_cls2.tci_name,  BLANK); 

strcpy(kms_j)tr->oki_tgt_cls2.common_attr,  "OBJECTID");  I*  default  common  attr  */ 
kmsj)tr->oki_tgt_cls2.tci_tgt_attrs  =  NULL; 
kmsj)tr->oki_tgt_cls2.tcLconditions  =  NULL; 

I*  pointer  to  process  actual  ool  request  *! 
ool_req  =  o_curr_req_ptr->ri_obj_req->ori_req; 

in_char  =  stmcmp(ool_req,  1);  /♦  Checks  to  see  if  the  request 

involves  a  covering  cons  •  act*/ 
strcpy(covcr_tcmp,  ool_req); 
new_ool_req  =  cover_temp; 
if  (in  char  =  0) 

{ 

/*  Sends  request  to  chcck_coverO  to  verify  if  it  is  a  valid 
*  covering  request*/ 

new_ool_req  =  check_cover(new_ool_req); 

} 

else 

1 

new_ool_req  =  ool_req; 

}  /♦End  if(char  *=  0)*/ 


strcpy(temp_str,  BLANK);  /*  temp  string  for  tokens  */ 
i  =  0; 

while  (♦new_ool_req  !=  *  ’) 

{ 

if  (*new_ool_req  =  ’.’) 

{ 

temp_str[i]  =  ND'; 

strcpy(kms_ptr->oki_tgt_cls  1  .tci_name,  temp_str); 
requested_class  =  find_class(ool_info_ptr->oi_curT_db. 
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cdi_db.dn_obj->odn_first_cls,  temp_str) 


strq)y(tcmp_str,  BLANK); 
i*0; 

) 

else 

{ 

temp_str[i]  =  *new_ool_req; 

-H-i; 

} 

■H-new_ool_req; 

} 

tcmp_str[i]  ='N0’; 
i  =  0; 

if  (!strcmp(temp_str,  "RETRIEVE")) 
ool_info_ptr->oi_operation  =  ExecRetReq; 
else  if  (!strcmp(temp_str,  "INSERT")) 
ool_info_ptr->oi_opcration  =  ExecInsReq; 
else 

t*  other  operations  are  not  implemented  yet 
if  (!strcmp(tcmp_str,  "DELETE")) 
ooLinfo_ptr->oLoperation  =  ExecDelReq; 
else  if  (!strcmp(temp_str,  "UPDATE")) 
ool_info_ptr->oi_operation  =  ExecUpdReq;  *'! 

{ 

ooLinfo_ptr->oi_operation  =  ExecNoReq; 
return ; 

} 

strcpy(temp_str,  BLANK); 

for  ( ;  (*new_ool_req  = '  ’);  ++new_ool_req) 

;  /*  eat  the  blanks  in  between  */ 

switch  (ool_info_ptr->oi_operation) 

{ 

case  ExecRetReq: 

while  (*new_ool_req  !=  ’  ’  &&  ♦ncw_ool_req  != ',’) 

{ 

if  (*new_ooI_rcq  = '.') 

{ 

temp_str[i]  =  'NO'; 

strcpy(kms_ptr->oki_tgt_clsl  .common_attr,  temp_str); 
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find_coinponent_class(kms_ptr,  tenip_str,  requested.class): 
strcpy(tcmp_str,  BLANK); 
qualified.attr  =  TRUE; 
i  =  0; 

} 

else 

{ 

teinp_str[i]  =  *new_ool_req; 

-H-i; 

} 

■H-new_ool  req; 

} 

teiTip_str[i]  =  'SO'; 

while  (strcmp(temp_str,  "IF*)) 

{ 

insert_target_attr(kms_ptr,  temp_str,  requested_class, 

qualified_attr); 

strcpy(temp_str,  BLANK); 
qualified.attr  =  FALSE; 

for  ( ;  (♦new_ool_req  =  "  II  *new_ool_req  ~  ’,’);  -H-new_ool_req) 
;  I*  eat  blanks  or  commas  */ 

if  (*new_ool_rcq  =  'SO')  /*  end  of  request  is  reached  *! 
break; 

i  =  0; 

while  (*new_ool_req  !=  "  &&  *new  ool_req  != ',') 

{ 

if  (*new_ool_rcq  = '.') 

{ 

temp_str[il  =  "SO'; 

strcpy(kms_ptr->oki_tgt_clsl.common_attr,  temp_str); 
find_component_class(kms_ptr,  temp_str,  requested_class); 
strcpy(temp_str,  BLANK); 
qualified_attr  =  TRUE; 
i  =  0; 

} 

else 

{ 

temp_str[i]  =  *new_ool_req; 

++i; 

} 
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++ncw  ool_req; 

} 


tcmp_str[i]  =  'VO'; 

}  /*  end  while  "IF"  &&  BLANK  */ 


if  (!strcmp(temp_str,  "IF'))  /*  condition  part  begins  */ 

{ 

stiicpy(tenip_str,  BLANK); 

for  ( ;  (*new_ool_req  = ' ');  ■H-new_ooLreq) 

;  /*  eat  blanks  */ 

i  =  0; 

while  (*new_ool_req  !=  'VO')  /*  while  not  end  of  request  ♦/ 

{ 

if  (*new_ool_req  == '.') 

{ 

temp_str[i]  =  "VO'; 

strcpy(kms_ptr->oki_tgt_clsl  .conimon_attr,  ten^_str); 
fmd_component_class(kms_ptr,  tcmp_str,  requested_class); 
strcpy(temp_str,  BLANK); 
qualified_attr  =  TRUE; 
i  =  0; 

) 

else  if  (*new  ool_req  « ' '  &&  conjunct_exist(new_ool_req)) 

{ 

temp_str[i]  =  'VO'; 

insert_condition(knisj)tr,  temp_str, 

requested_class,  qualified_attr); 

-H-new_ool_req;  ++new_ool_req;  -i-+new_ool_req; 
i=0; 

strcpy(temp_str,  BLANK); 
qualifled.attr  =  FALSE; 

} 

else 

{ 

temp_str[i]  =  ♦new_ooI_req; 

++i; 

} 

++new_ool_req; 

)  /*  end  while  ♦/ 

/*  one  more  insert  for  the  last  condition  */ 
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temp_str[i]  =  >0’; 

inscrt_condition(kins_ptr,  tcmp_str, 

requested.class,  qualified.attr); 

}  /*  end  if  (!strcinp(tcmp_str,  "EF"))  */ 

break; 

case  ExeclnsReq: 

I*  create  .insert_file  by  parsing  INSERT  request  */ 
tenip_file  =  fopen(".insert_file",  "w"); 
^rintf(temp_file,  "%s\n@@\n%s\n", 

ool_info_ptr->oi_curr_db.cdi_dbname, 

kms_ptr->old_tgt_clsl.tci_naine); 

while  (*new_ool_req  !=  'VO') 

{ 

if  (*new_ool_req  != ' ') 
if  (♦new_ool_req  = 

{ 

temp_str[i]  = 

fprintf(temp_file,  "%s\t",  temp_str); 
i  =  0; 

strcpy(temp_str,  BLANK); 

} 

else 

{ 

temp_str[i]  =  *new_ool_req; 

-H-i; 

) 

++new_ool_req; 

}  /*  end  while  */ 
temp_str[i]  =  \D'; 

fprintf(temp_file,  "%sNn$Vn",  temp_str); 
fclose(tcnip_file); 

break; 

case  ExecDelReq; 
break; 
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case  ExecUpdReq: 
break; 

default: 

break; 

}  /*  end  switch  */ 

#ifdef  EnExFlag 

printfC'Exit  parsc_ool_requcsfyn"); 
/*  tcst_parscr(kms_ptr);  */ 

#endif 

}  /*  end  parse_ool_requcst  */ 


t*  This  procedure  processes  a  request  which  involves  a  covering  construct 

*  It  first  checks  to  see  if  a  covering  file  exists  for  this  database.  If 

*  no  file  exists,  die  procedure  is  terminated.  If  a  file  exists,  a  check 

*  is  made  to  see  if  there  is  a  covoing  construct  which  has  die  same  name 

*  as  the  request  It  then  verifies  that  the  covering  object  is  the  same 

*  and  if  the  requested  object  falls  within  the  scope  of  the  covering 

*  constract  The  source  code  for  the  creation  of  covoing  constracts  is 

*  located  in  the  file  o.cover.c,  located  in  the  Ul  directory. 

*/ 

char  *chcck_covcr(rcq_ptr) 


char  *reqj)tr, 

{ 

char  t6mp[InputCols], 

cover_name[InputCols], 
from_obj[InputCols], 
to_obj[InputQ)ls], 
cover_filc[FNLcngth  +  3]; 
char  ♦str_chk, 

♦stringl, 

*string2, 

♦strings, 

*string4, 

♦strings  =  NULL; 
struct  obj_dbid_node  ♦db_ptr; 

FILE  ♦fid; 


dbjitr  =  cuscr_objj)tr->ui_U_type.li_ool.oi_curr_db.cdLdb.dn_obj; 
strcpy(covcr_filc,  db_ptr->odn_namc); 
strcat(cover_file,  ".cover");  /♦Gets  name  of  covering  file  for 
current  database^/ 

str_chk  =  req_ptr; 

fid  =  fopen  (cover_file,  "r"); 

if  (fid  ==  NULL)  /♦No  file  exists  for  current  database^/ 

{ 

printf("\nNo  covering  file  exists  for  this  database.\n"); 
printfC'CJuery  refused.NriVn"); 
i*  fclose(fid);^/ 
return  str.chk; 

) 

else 


80 


{ 

/*Get  covering  construct  name  and  name  of  covering  object*/ 
string  1  =  strtok(str_chk, /*Gct  covering  object  name*/ 
string2  =  strtok(NlJLL. /*(3et  covering  construct  name*/ 
Strings  =  strtok(NULL,  "0");  /*Gct  rest  of  querry*/ 

++string3; 

strcpy(temp,  stringS); 
stting4  =  temp; 

Strings  =  strtok(string4, /*Get  requested  object  name*/ 

while  (fscanf(fid,  "%s",  cover_name)  !=  EOF) 

{ 

/*If  covering  construct  name  is  found*/ 
if  (!strcmp(cover_name,  string!)) 

( 

fscanf(fid,  "%s",  firom_obj); 

/*If  covering  object  is  found*/ 
if  (!strcmp(from_obj,  string  1)) 

{ 

fscanf(fid,  "%s",  to_obj); 

/*Scan  file  until  the  end  of  covering  construct  is  reached*/ 
while  (strcmp(to_obj,  "@@")) 

{ 

/♦If  requested  object  is  within  the  scope  of 
the  covering  construct*/ 
if  (!strcmp(to_obj,  stringS)) 

{ 

fclose(fid); 

return  stringS;  /*Retum  request  to  be  retrieved*/ 

) 

else 

{ 

fscanf(fid,  ''%s",  to_obj); 

}  /♦End  sttcmp(string5)*/ 

}  /*Endwhile(fscanf"@@")*/ 

}  /*End  if(strcmp  string  1)*/ 

}  /*End  if(strcmp  string!)*/ 
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fscanf(fid.  •’Vn"); 

}  /*EndwhUc(fscaiif!=EOF)*/ 

}  /*Endif(fid  =  NULL*/ 
fclose(fid); 

/*No  covering  construct  was  found  matching  the  query.*/ 
printf("VnNo  covering  construct  exists  for  this  query.Nn"); 
printf("VnQucry  refuscd.\n\n"); 
return  str_chk; 

}  /*End  check_cover()*/ 
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C.  SOURCE  CODE  FOR  THE  OBJECTID  GENERATOR 


/ 

************************************************************************ 

****f 

/*  This  function  gets  the  time  of  day  (GMT)  from  the  system,  and  parses  it  */ 

I*  into  an  8  digit  number,  which  is  then  used  as  an  objectID.  This  function*/ 
t*  is  called  by  mssJoadO  and  returns  a  character  string.  */ 

/ 

****! 


char  ♦gct_objectidO 

( 

time_t  mytimc  =  0; 
long  int  years; 
long  int  remainder, 
long  int  yearseconds; 
long  int  julianday; 
long  int  dayremainder; 
long  int  dayseconds; 
long  int  hourseconds; 
long  int  minuteseconds; 
long  int  objectid; 
char  today; 
int  microseconds; 
int  hours; 

int  minuteremainder, 
int  minutes; 
int  seconds; 
int  i  =  0; 
intj  =  0; 
long  int  temp; 
int  int_aiTay[9]; 
char  tcmp_array[9]; 

struct  timeval  Q); 
struct  timeval  tzp; 

mytime  =  gettimeofday(&tp,  &tzp); 

/♦Total  secs  mod  #  secs  in  one  year  =  total  years  since  1970*/ 
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years  » tp.tv_sec  /  31536000; 

/*coii^utes  die  elapsed  years*/ 

yearseconds  =  years  ♦  31536000;  /*  23  years  *  #  sec/year  */ 

remainder  «  q).tv_sec  -  yearseconds; 
julianday  -  remainder  /  86400; 

/*conq>utes  the  elapsed  days  (julian  day)  */ 

dayseconds  =  julianday  ♦  86400;  /*  julianday  *  86400  sec^ear*/ 

dayiemainder  =  ^.tv_sec  -  (yearseconds  +  dayseconds); 

hours  =  dayremainder  /  3600;  /*  leftover  day  in  seconds  */ 

/"confutes  die  elapsed  hours*/ 
hourseconds  =  hours  *  3600; 

minuteiemainder  =  tp.tv_sec  -  (yearseconds  +  dayseconds  +  hourseconds); 
minutes=  minuteremainder  /  60; 
minuteseconds  =  minutes  *  60; 

/*computes  the  elapsed  seconds*/ 
seconds  =  tp.tv_scc  -  (yearseconds  +  dayseconds  + 
hourseconds  +  minuteseconds); 


/*computes  the  elapsed  milliseconds*/ 
microseconds  =  tp.tv_uscc  /  10000; 

/*Set  variable  temp  to  format  needed  for  objectid*/ 

temp  =  hours  *  1000000; 

temp  =  temp  +  (minutes  *  10000); 

ten^  =  temp  +  (seconds  *  100); 

temp  5=  temp  +  microseconds; 


/*Rcad  objectid  into  integer  array*/ 
int_array[0]  =  hours  / 10; 
int_array[l]  =  hours  %  10; 
int_array[2]  =  minutes  /  10; 
int_array[3]  =  minutes  %  10; 
int_array[4i  =  seconds  /  10; 
int_arTay[5]  =  seconds  %  10; 
int_array[6]  =  microseconds  / 10; 
int_array[7]  =  microseconds  %  10; 
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i»0; 


/•Convert  integer  string  into  character  string*/ 
while  (i  <  8) 

switch(int  arrayti]) 

{ 

case  (1) :  |  tcinp_aiTay[i]  =  *1';  break;) 
case  (2) :  { tcmp_array[i]  *  *2’;  break;) 
case  (3) :  { tcmp_aiTay[i]  =  ‘3';  break;) 
case  (4) :  { tenip_array[i]  *  '4';  break;) 
case  (5) :  { tcmp_aiiay[i]  =  '5';  break;) 
case  (6) :  { tcmp_array[i]  =  '6';  break;} 
case  (7) :  { teinp_aiTay[i]  =  7';  break;) 
case  (8) :  { teinp_array[i]  =  '8';  break;) 
case  (9) :  { temp_array[i]  =  '9';  break;) 
default  :  { tcmp_array[i]  =  'O';  break; ) 

} 

i++; 

} 

for  (j  =  0;  j  <  10000;  j-H-);  /♦Delays  program  to  prevent  duplicate  object  ids*/ 

return  tcmp_array; 

)  /*  end  get_objectid  function  */ 
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APPENDIX  C.  TUTORIAL  FOR  THE  OBJECT- 
ORIENTED  INTERFACE  ON  MDBS 


The  purpose  of  this  appendix  is  to  provide  the  user  with  a  taief  tutorial  of  the  Object- 
Oriented  Interface  on  MDBS.  Snapshots  of  the  system  output,  along  with  a  brief 
description  of  what  is  occurring  will  be  provided  to  the  user.  Entries  made  by  the  user  are 
depicted  in  bold  print 


A.  ACCESSING  THE  OBJECT-ORIENTED  INTERFACE 

To  access  the  Object-Oriented  Interface,  the  user  must  first  log  on  to  DBS,  using  the 
CS4322  account  Once  the  user  has  entered  the  account  he  or  she  must  go  to  the  directory: 
mdbs/rich/run.  To  start  mdbs,  the  user  must  verify  the  following:  (1)  There  are  no  mdbs 
processes  running.  This  is  accomplished  by  typing  “ps  -ax”  at  the  command  line.  If  any 
mdbs  processes  are  running,  type  the  command  “stop.cmd”  and  the  processes  will  be 
terminated.  (2)  Verify  there  is  no  data  on  the  disk  from  a  previous  session.  To  verify  the 
absence  of  data,  the  user  should  type  “pry”  at  the  command  prompt.  This  should  display  a 
line  of  zeros.  If  text  appears,  the  user  should  press  “CNTRL-c”  to  exit  and  then  enter  “zero” 
at  the  command  prompt  After  the  zeroing  process  is  complete,  the  user  is  required  to  enter 
“nm”  at  the  command  prompt  This  will  stan  the  Multilingual/Multimodel  system.  After 
the  system  is  loaded,  the  screen  bellow  will  appear. 

Select  an  operation: 

(a)  -  Execute  the  attribute-based/ABDL  interface 
(r)  -  Execute  the  relational/SQL  interface 
(h)  -  Execute  the  hierarchical/DL/I  interface 

(n)  -  Execute  the  network/CODASYL  interface 
(f)  -  Execute  the  fiinctional/DAPLEX  interface 

(o)  -  Execute  the  object-oriented/OOL  interface 
(x)  -  Exit  to  the  operating  system 

Select->  o 
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The  user  should  verify  that  twelve  processes  (six  controllers  and  six  backends)are  on-line 
by  running  the  “ps  -ax”  command  in  a  separate  window.  If  there  are  not  twelve  processes 
running,  select  “x”  from  the  menu.  When  the  system  has  shut  down,  run  the  “stop.cmd” 
again  and  restart  the  system.  Repeat  this  procedure  until  twelve  processes  are  running. 
Note:  The  user  does  not  need  to  zero  the  database  because  no  data  has  been  loaded  to  the 
disk.  After  the  system  is  successfully  running  with  twelve  processes,  select  “o”  from  the 
menu  to  enter  the  object-oriented  interface. 

B.  SELECTING  A  DATABASE 

After  selecting  the  Object-Oriented  Interface,  the  user  will  be  presented  with  the 
following  menu  for  processing  a  database. 


Enter  type  of  operation  desired 
(1)  •  load  new  database 
(p)  -  process  existing  database 
(x)  -  return  to  the  MLDS/MDBS  system  menu 

Action  ™  > 


At  this  point,  the  user  has  two  options.  Selecting  “1”  allows  the  user  to  load  a  new 
database.  This  is  done  whenever  the  interface  is  first  used  or  when  additional  databases  are 

required.  M  DBMS  allows  the  user  to  run  multiple  databases  simultaneously,  although 
access  is  restricted  to  one  database  at  a  time.  Selecting  “p”  allows  the  user  to  process  a 
database  which  has  been  previously  loaded  during  the  current  session.  Selecting  “x”  returns 
the  user  to  the  previous  menu.  Since  this  is  the  beginning  of  a  new  session,  we  will  chose 
“1”  and  load  a  new  database.  This  selection  produces  the  menu  display  below: 
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Enter  name  of  database  — >FAMILY 


The  user  is  prompted  for  the  name  of  the  database  which  is  to  be  loaded.  If  the  user 
is  loading  the  database  from  disk,  the  name  entered  must  match  die  name  of  the  database 
in  the  flle.  This  is  also  necessary  for  referencing  template  and  descriptor  files  which  will  be 
discussed  later  in  this  tutorial. 

After  the  user  enters  the  name  of  the  database,  the  menu  changes  as  shown  below. 
This  menu  request  the  mode  of  input  for  the  schema.  The  user  may  select  input  from  a  file 
or  may  choose  to  enter  the  schema  manually  from  the  screen.  In  this  tutorial  we  will  select 
“f  ’  and  read  the  input  from  a  text  file. 


Enter  mode  of  input  desired 

(f)  •  read  in  a  group  of  creates  from  a  file 
(t)  -  read  in  aeates  from  the  terminal 
(x)  -  return  to  the  main  menu 

Action  ™  > 

Selecting  “f  ’  will  cause  the  system  to  prompt  the  user  for  the  name  of  the  file.  For 
loading  the  schema,  the  convention  used  is  <filename>ooldb.  For  this  tutorial  we  will  use 
the  file  FAMILYooldb.  Below  is  an  example  of  the  screen  display  for  this  procedure. 
Figure  23  shows  the  text  file,  FAMILYooldb,  for  the  FAMILY  database  schema. 


What  is  the  name  of  the  CREATE/QUERY  file  — >FAMILYooldb 


The  user  is  then  asked  if  he  or  she  desires  to  use  the  existing  descriptor  file.  The  screen 
display  is  shown  below.  The  contents  of  the  descriptor  file  for  the  FAMILY  database  is 
shown  in  Figure  24.  The  earlier  reference  to  the  importance  of  naming  the  database 
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CLASS  GEORGE 
SUBCLASS  MIKE 
SUBCLASS  PAUL 
OBJECTID  INTEGER 
FIRSIN  CHAR  10 
LASTN  CHAR  10 
SALARY  INTEGER 

@ 

CLASS  BERTHA 
SUBCLASS  SUE 
SUBCLASS  JOE 
OBJECTID  INTEGER 
FIRSTN  CHAR  10 
LASTN  CHAR  10 
SALARY  INTEGER 

@ 

GLASS  MIKE 
SUBCLASS  GEORGE 
@ 

CLASS  PAUL 
SUBCLASS  GEORGE 
SUBCLASS  PAULLA 
@ 

CLASS  SUE 
SUBCLASS  BERTHA 
@ 

CLASS  JOE 
SUBCLASS  BERTHA 
SUBCLASS  TODD 

CLASS  PAULLA 
SUBCLASS  PAUL 
SUBCLASS  ANDY 
SUBCLASS  SAMANTHA 

CLASS  TODD 
SUBCLASS  JOE 
@ 

CLASS  ANDY 
SUBCLASS  PAULLA 
@ 

CLASS  SAMANTHA 
SUBCLASS  PAULLA 


Figure  23:  The  Schema  Text  File  for  the  Family  Database:  FAMILYooldb 


conectly  comes  into  play  here.  If  the  user  is  not  consistent  in  the  naming  of  his  or  her 
database,  the  established  descriptor  file  will  not  be  used. 


Would  you  like  to  use  the  existing  descriptor  file,  FAMILY.d, 
for  indexing  information?(y  cff  n) 

Action  —  >y 

If  the  user  replies  to  the  above  query  with  “n*\  the  database  schema  will  not  load  and 
the  previous  menu  will  be  re-displayed.  If  the  user  responds  with  “y”,  the  schema  will  be 
loaded  using  the  current  descriptor  file.  NOTE:  If  the  schema  file  has  been  modified,  the 
user  must  delete  the  “.d”  and  the  “.t”  files  associated  with  that  database.  These  files  are 
found  in  the  UserFiles  subdirectory  of  the  MDBS  directory.  After  selecting  ‘y ’,  the  menu 
shown  below  will  be  re-displayed,  giving  the  user  the  option  of  loading  an  additional 
database  or  processing  a  previously  loaded  database.  In  our  example  we  will  process  the 
existing  database  FAMILY. 


Enter  Q'pe  of  operation  desired 
G)  -  load  new  database 
(p)  -  process  existing  database 
(x)  -  return  to  the  MLDS/MDBS  system  menu 

Action  —  >  p 

Enter  name  of  database  — >FAMILY 

C.  LOADING  DATA  INTO  THE  DATABASE 

After  selecting  a  database  to  process,  the  user  is  ready  to  proceed  to  the  next  menu. 
The  menu  shown  below  provides  the  user  with  all  the  functions  needed  to  manipulate  the 
data.  We  will  review  each  item  in  turn. 
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DESCRIPTOR  FILE;  FAMILY. d 


FAKOLY 
TEMPbs 
!  George 
I  Bertha 
IMike 
IPtuil 
tSue 
!  Joe 
IPaulla 
!Todd 
!  Andy 
!  Samantha 


TEMPLATE  FILE:  FAMILY. t 

FAMILY 

10 

5 

Geotge 

TEMPs 

OBJECTIDi 

FIRSTOs 

LASTNs 

SALARY! 

5 

Bertha 

TEMPs 

OBJECTIDi 

FIRSTNs 

LASTNs 

SALARY! 

2 

Mike 

TEMPs 

OBJECTID! 

2 

Paul 

TEMPs 

OBJECTID! 


2 

Sue 

TEMPs 

OBJECTID! 

2 

Joe 

TEMPs 

OBJECTID! 

2 

PauUa 

TEMPs 

OBJECTID! 

2 

Todd 

TEMPs 

OBJECTID! 

2 

Andy 

TEMPs 

OBJECTID! 

2 

Samantha 

TEMPs 

OBJECTID! 


Figure  24:  Descriptor  and  Template  Files  for  the  FAMILY  Database 


Enter  your  choice 

(d) '  display  schema 

(c)  -  create  covering  relation  between  two  objects 

(m)  -  mass  load  lErom  a  data  file 

(f)  -  read  in  a  group  of  queries  from  a  file 

(t)  -  read  in  queries  from  the  terminal 

(x)  •  return  to  previous  moiu 

Action  —  > 


Before  we  manipulate  records,  we  must  first  load  the  raw  data  into  die  database.  This 
is  done  by  selecting  “m”  from  the  menu  above.  The  system  will  then  ask  the  user  for  the 
name  of  the  record  file.  As  with  the  schona,  the  data  file  maintains  the  same  naming 
conventions.  The  name  of  the  data  file  is  <filename  j>.  In  our  case  we  will  use  the  file 
FAMILY .r.  The  screen  display  for  this  sequence  is  shown  below.  Figure  25  shows  the 
contents  of  the  FAMILY.r  record  file.  Figure  26  shows  the  screen  display  as  records  are 
loaded  into  the  database.  Note  that  the  object-ids  in  the  record  file  do  not  match  the  object- 
ids  in  the  screen  display.  This  is  because  the  Object-Oriented  intoface  creates  its  own 
object-ids  which  are  generated  from  die  system  clock.  The  object-ids  in  the  record  file  are 
used  as  a  place  holder  to  ensure  the  propa  matching  of  attributes  in  the  template  file  and 
the  record  file. 


Enter  name  of  record  file  — >FAMILY.r 


Once  the  mass  load  procedure  is  complete,  the  menu  below  will  appear.  We  have  seen 
this  menu  before.  The  options  for  this  menu  remain  the  same.  This  gives  the  user  the 
opportunity  to  switch  to  another  database  in  order  to  mass  load  or  manipulate  records.  We 
will  select  option  “p”  and  continue  processing  the  FAMILY  database. 
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FANDLY 

@ 

GEORGE 

1  George  Jones  50000 

@ 

BERTHA 

2  Berdia  Smith  75000 

@ 

MIKE 

3  Mike  Jones  32000 

@ 

PAUL 

4  Paul  Jones  45000 

@ 

SUE 

5  Sue  Smith  30000 

@ 

JOE 

6  Joe  Smith  18000 

@ 

PAULLA 

7  Paulla  Jones  100000 

@ 

TODD 

8  Todd  Smith  200 

@ 

ANDY 

10  Andy  Jones  0 

@ 

SAMANTHA 

11  Samantha  Jones  0 
$ 

NOTE:  FAMILY  indicates  the  name  of  the  database  which  is  associated  with  this 
record  file.  The  indicates  an  end  of  record.  The  *T’  indicates  end  of  file.  The 
capitalized  names  are  the  names  of  each  object  class.  The  attribute  values  are  listed  on 
the  second  line  of  each  record.  For  this  database,  they  are  from  left  to  right:  objea-id, 
first  name,  last  name,  salary. 


Figure  25:  Record  File  for  the  FAMILY  Database:  FAMILY.r 
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[INSERT  (<TEMP,  Gcorgo,  -cOBJECITD,  03065375>,  <FIRSTN,  Gcorgo,  <LASTN. 
Joncs>,  <SALARY,  50000>)] 

[INSERT  (<TEMP,  Bcrtha>,  <OBJECnD.  03065379>,  <FIRSTN,  Bcrtha>,  <LASTN, 
Simth>,  <SALARY,  75000>)1 

[INSERT  (<TEMP,  Gcorgo.  <OBJECnD,  03065380>,  <FIRSTN,  Miko,  <LASTN,  Joiics>, 
<SALARY,  32000>)] 

[INSERT  (^MP,  Miko,  <OBJECnD.  03065380>)] 

[INSERT  (<TEMP,  Gcorgo,  <OBJECnD,  03065382>,  <FIRSTN,  Paul>,  <LASTN,  Jonco, 
<SALARY.  45000>)] 

[INSERT  (^TEMP,  Paul>.  <OBJECnD,  03065382>)] 

[INSERT  (<TEMP,  Bcrtho,  <OBJECnD,  03065385>,  <FIRSTN,  Suo,  <LASTN,  Smith>, 
<S  ALARY.  30000>)] 

[INSERT  (<TEMP,  Suo,  <OBJECnD,  03065385>)] 

[INSERT  (<TEMP,  Bcrtho,  <OBJECnD.  03065387>.  <FIRSTN,  Joo,  <LASTN,  Sinith>, 
<SALARY,  18000>)] 

[INSERT  (<TEMP,  Joo,  <OBJECnD.  03065387>)] 

[INSERT  (<T1EMP,  Gcorgo,  <OBJECnD,  03065390>,  <FIRSTN,  PauUo,  <LASTN, 
Jonco,  <SALARY,  100000>)] 

[INSERT  («^MP.  Paul>.  <OBJECnD.  03065390>)] 

[INSERT  (<OTMP,  PauUo,  <OBJECnD.  03065390>)3 

[INSERT  (<aEMP,  Bcrtho,  <0B  JECTID,  03065394>,  <FIRSTN,  Todd>,  <LASTN,  Simth>, 
<SALARY,  200>)] 

[INSERT  «rEMP.  Joo,  <OBJECnD,  03065394>)] 

[INSERT  (<TEMP,  Todd>,  <OBJECnD,  03065394>)] 

[INSERT  (<TEMP,  Gcorgo,  <OBJECnD,  03065397>,  <FIRSTN,  Andy>,  <LASTN, 
Jonco,  <SALARY,  0>)] 

[INSERT  (<TEMP,  Paul>,  <OBJECnD.  03065397>)] 

[INSERT  (<TEMP,  PauUo,  <OBJECTID,  03065397>)] 

[INSERT  (<TEMP,  Andy>,  <OBJECnD,  03065397>)] 

[INSERT  (<TEMP,  Gcorgo,  <OBJECnD,  03065399>,  <FIRSTN,  Samantho,  <LASTN, 
Jonco,  <SALARY,  0>)] 

[INSERT  (<aBMP,  Paul>,  <OBJECnD,  03065399>)] 

[INSERT  (<TEMP,  PauUo.  <OBJECnD,  03065399>)1 
[INSERT  (-^MP,  Samantho,  <OBJECnD,  03065399>)] 


Figure  26:  Screen  Display  of  the  File  FAMILY.r  Being  Loaded  Into  the  Database 
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Enter  type  of  operation  desired 
Q)  -  load  new  database 
(p)  -  process  existing  database 
(x)  •  return  to  the  MLDS/MDBS  system  menu 

Action  —  >  p 

Enta  name  of  database  — >FAMILY 


D.  CREATING  A  COVERING  RELATION 

The  Object-Oriented  database  now  has  the  ability  to  access  data  via  a  covering 
relation.  In  this  section  we  will  create  covering  constructs  between  object  classes,  allowing 
the  user  access  to  the  data  in  one  object-class  through  anotha  object  class. 

Having  chosen  to  continue  processing  the  FAMILY  database,  the  record 
manipulation  menu  is  redisplayed.  As  seen  below,  we  will  select  option  “c”  in  order  to 
create  one  or  more  covering  relationships. 


Enter  your  choice 

(d)  -  display  schema 

(c)  -  create  covering  relation  between  two  objects 

(m)  -  mass  load  from  a  data  file 

(f)  -  read  in  a  group  of  queries  from  a  file 

(t)  -  read  in  queries  from  the  terminal 

(x)  -  return  to  previous  menu 

Action  —  > 


Having  selected  the  covering  option,  the  screen  will  clear  and  the  covering  menu  will 
be  displayed  as  shown  below.  The  covering  menu  gives  the  user  several  options,  including: 
displaying  existing  covering  constructs,  displaying  classes  available  within  the  current 
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database  for  use  in  creating  a  covering  construct,  and  establishing  a  covering  construct 
between  two  objects.  We  will  review  each  option  in  turn. 


Enter  type  of  operation  desired 

(d)  -  Display  Existing  Covering  Constructs 

(c)  -  Display  Available  Classes 

(e)  •  Establish  a  Covering  Construct  Between  Two  Objects 
(x)  -  Return  to  previous  menu 

Action  “  > 


The  first  option  in  the  covering  menu  allows  the  user  to  display  any  existing  covering 
constructs.  When  displaying  covering  constructs,  the  system  reads  the  covering  file 
associated  with  each  database.  If  the  database  has  been  newly  created,  no  covering  file  for 
that  database  should  exist  Covering  files  are  deleted  when  the  users  exits  from  the 
Multimodel/Multilingual  system.  In  other  words,  the  covering  file  exists  only  during  the 
duration  of  the  current  session.  If  we  select  “d”  when  no  covering  file  exists,  we  will  see 
the  reply  shown  below.  After  we  create  a  covering  constract  we  will  return  to  this  menu 
selection  and  show  a  display  of  the  existing  covering  constructs. 


No  covering  constructs  exists  for  this  database 

Enter  type  of  operation  desired 

(d)  -  Display  Existing  Covering  Constructs 
(c)  -  Display  Available  Classes 

(e)  -  Establish  a  Covering  Construct  Between  Two  Objects 
(x)  -  Return  to  previous  menu 

Action  —  > 


Before  creating  a  covering  relation,  it  is  sometimes  useful  to  see  which  objects  are 
available  in  the  database.  Selecting  **c”  displays  all  the  objects  available  in  the  current 
database.  Since  spelling  the  object’s  name  is  important,  the  user  should  di^lay  the 
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available  object  classes  prior  to  creating  a  covering  relationship.  The  screen  display  is 
shown  below. 


Database  Name :  FAMILY 
CLASS  GEORGE 
CLASS  BERTHA 
CLASS  MIKE 
CLASS  PAUL 
CLASS  SUE 
CLASS  JOE 
CLASS  PAULLA 
CLASS  TODD 
CLASS  ANDY 
CLASS  SAMANTHA 

Enter  type  of  operation  desired 

(d)  -  Display  Existing  Covering  Constructs 
(c)  -  Display  Available  Qasses 

(e)  -  Establish  a  Covering  Construct  Between  Two  Objects 
(x)  -  Return  to  previous  menu 

Action  —  > 


The  list  of  available  objects  is  listed  in  the  order  they  appear  in  the  link  list  in  memory. 
These  objects  are  not  grouped  by  class,  so  the  possibility  exists  that  two  objects  from  the 
same  class  may  be  chosen.  This  is  not  a  problon  because  the  procedure  that  creates  the 
covering  construct  will  not  allow  two  objects  in  the  same  object  hierarchy  to  be  joined  in  a 
covering  relationship.  If  this  hi^>pens,  the  system  will  notify  the  user  that  this  is  the  case, 
and  the  usor  can  try  again. 

Having  displayed  the  list  of  objects  available  in  the  database,  we  can  now  create  a 
covering  relation.  To  refresh  the  reado*,  covoing  is  the  mapping  of  an  object  in  one 
hierarchy  to  an  object  class  in  anothn  hierarchy.  The  covered  object  class  can  consist  of 
one  object,  several  related  objects,  or  an  entire  object  hierarchy.  When  creating  a  covoing 
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relation  between  two  objects  in  the  Object-Oriented  Interface,  the  user  can  define  the  scope 
of  the  relation  by  setting  the  number  of  objects  above  and  below  the  covered  object  within 
its  hierarchy. 

To  create  a  covering  relation,  the  usa  selects  “e”  from  the  menu  shown  above.  The 
user  is  then  prompted  to  enter  the  name  of  the  covering  relation.  This  naming  convoition 
allows  the  user  to  define  more  than  one  covering  construct  for  each  object  or  define  tlw 
same  type  of  covering  construct  for  different  objects.  After  naming  the  relation,  the  user  is 
prompted  for  the  name  of  the  covering  object  and  then  the  name  of  the  object  to  be  covered. 
Having  received  this  information,  the  system  finds  the  target  objects.  If  either  of  the  objects 
is  not  found,  the  system  informs  the  user  of  the  situation  and  returns  to  die  covering  menu. 
If  the  system  finds  both  objects,  it  performs  a  check  to  see  if  the  two  objects  are  in  the  same 
object-class  hierarchy.  If  both  objects  are  in  the  same  hierarchy,  the  system  informs  the  user 
that  this  is  the  case  and  returns  the  user  to  the  covering  menu.  This  is  because  covering  only 
applies  between  two  objects  residing  in  diffo’ent  hierarchies. 

If  the  above  conditions  are  met,  the  system  will  prompt  the  user  for  verification.  If  the 
user  answers  “yes”,  the  covering  process  continues.  If  “no”  is  selected,  the  covering  process 
is  terminated  and  the  covering  menu  returns.  Having  made  a  selection,  the  user  is  prompted 
to  define  the  scope  of  the  covering  relationship.  The  user  is  prompted  for  the  number  of 
levels  above  and  below  the  covered  object  After  the  system  receives  this  input  it  writes 
the  name  of  the  relation,  the  covering  object’s  name,  and  the  covered  object’s  name  to  the 
covering  file  associated  with  the  current  database.  Once  these  names  are  written  to  the 
covering  file,  the  system  searches  the  covering  hierarchy  for  objects  within  the  declared 
scope  of  the  covering  relation.  As  each  covered  object  is  found,  die  system  writes  the 
object’s  name  to  the  covering  file.  Upon  completion  of  the  search,  the  covering  file  is 
closed  and  the  user  is  returned  to  the  covering  menu.  The  screen  di^lay  of  the  sequence  of 
events  mentioned  above  is  shown  below. 
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Enter  the  name  of  the  covering  construct  you  wish  to  create 
Use  all  CAPITAL  letters  when  entering  name. 

IN-LAW 

Enter  the  name  of  the  object  you  wish  to  cover  FROM. 

Use  all  CAPITAL  letters  when  entering  name. 

TODD 

Enter  the  name  of  the  object  you  wish  to  cover  TO. 

Use  all  CAPITAL  letters  when  entering  name. 

PAULLA 

A  covering  relation  is  being  created  from  TODD  to  PAULLA 
Is  this  correct  (y  or  n)?  y 

How  many  levels  above  PAULLA  should  the  covering  construct  include?  1 
How  many  levels  below  PAULLA  should  the  covering  construct  include?  2 
The  covering  construct  has  been  completed. 

Enter  type  of  operation  desired 

(d)  -  Display  Existing  Covering  Constructs 
(c)  -  Display  Available  Qasses 

(e)  -  Establish  a  Covoing  Construct  Between  Two  Objects 
(x)  -  Return  to  previous  menu 

Action  —  > 


Once  a  covering  construct  is  created,  we  can  select  “d”  from  the  covering  menu  and 
display  the  existing  covering  constructs.  The  exan^le  below  shows  a  covering  file  with  two 
covering  constructs.  Note:  the  BUSINESS  covering  construct  contains  no  additional 
objects.  This  is  because  the  scope  of  the  covoing  relation  was  defrned  to  be  zero  above  and 
zero  below  the  covered  object  Figure  14,  in  Chapter  IV  of  this  thesis,  shows  die  contents 
of  die  covoing  file,  FAMILY.cover.  The  covering  file  for  each  database  is  maintained  in 
the  mdbs/richfrun  directory  during  the  duration  of  the  sessions. 
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IN-LAW  :  TODD  covcts  PAULLA  and  includes  the  object(s):  PAUL  ANDY 
SAMANTHA 

BUSINESS  :  SAMANTHA  covers  JOE  and  includes  the  objects): 

The  covering  construct  has  been  completed. 

Enter  type  of  operation  desired 

(d)  -  Display  Existing  Covering  Constructs 
(c)  -  Display  Available  Classes 

(e)  -  Establish  a  Covering  Construct  Between  Two  Objects 
(x)  -  Return  to  previous  menu 

Action  —  > 


E.  PERFORMING  QUERIES  ON  THE  OBJECT-ORIENTED  DATABASE 

Having  completed  the  creation  of  a  covering  construct,  we  can  exit  the  covering  menu 
by  selecting  “x”  and  return  to  the  database  operation  menu  shown  below. 


Enter  your  choice 

(d)  -  display  schema 

(c)  -  create  covering  relation  between  two  objects 

(m)  -  mass  load  from  a  data  file 

(f)  -  read  in  a  group  of  queries  from  a  file 

(t)  -  read  in  queries  from  the  terminal 

(x)  -  return  to  previous  menu 

Action  —  > 


The  interface  allows  the  user  to  perform  queries  on  data  in  two  ways.The  user  can 
load  a  list  of  queries  from  a  text  file  by  selecting  “f or  enter  queries  manually  from  the 
terminal  by  selecting  “t”.  Both  methods  use  the  same  format  for  listing  queries.  In  this 
tutorial  we  will  load  a  query  file  by  selecting  “f ’.  The  user  is  prompted  for  the  file  name. 
The  file  name  for  the  queries  can  be  any  nanw.  The  query  file  for  this  example  is 
FAMILYoolreq.  The  screen  display  for  this  sequence  of  events  is  shown  below.  The 
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contents  of  FAMlLYoolreq  is  shown  in  Figure  27.  The  screen  display  of  the  query  list  is 
shown  in  Figure  28. 

Action  —  >f 

What  is  the  name  of  the  CREATE/QUERY  file  — >FAMILYoolreq 


Having  loaded  a  list  of  queries  into  the  system,  the  user  can  select  a  query  for 
retrieval.  We  will  select  query  number  “1”.  The  screen  display  for  this  query  is  shown 
below.  It  is  important  to  note  that  a  query  on  an  object  not  only  retrieves  the  data  for  that 
object  but  all  its  subclasses  in  the  inheritance  hierarchy.  If  we  perform  query  “1 1”  in  Figure 
28,  only  the  data  for  SAMANTHA  will  be  retrieve  because  this  object  has  no  subclasses. 


Action  — 

>1 

• 

SALARY 

ILASTN 

■FIRSTN 

■OBJECITD  ■ 

50000 

Hones 

■George 

■03065375  ■ 

32000 

■Jones 

■Mike 

■03065380  ■ 

45000 

■Jones 

■Paul 

■03065382  ■ 

100000 

■Jones 

IPaulla 

■03065390  ■ 

0 

■Jones 

■Andy 

■03065397  1 

0 

■Jones 

■Samantha 

■03065399  ■ 

Pick  the  number  or  letter  of  the  action  desired 

(num)  -  execute  one  of  the  preceding  queries 

(d) 

redisplay  the  file  of  quoies 

(X) 

return  to  the  previous  menu 

Action  — 

> 

/File  Name :  FAMILYoolreq 

georgcjetrieve  objectid,  fostn,  lasm,  salary 

@ 

berthajvtrieve  objectid,  &stn,  lastn,  salary 

@ 

fnike.retrieve  objectid,  flrstn,  lastn 

@ 

paulj«tiieve  objectid,  firstn,  lastn 

@ 

sue.retrieve  objectid,  firstn,  lastn 

@ 

joe.retrieve  objectid,  firstn,  lasm 

@ 

paullajetrieve  objectid,  firsm,  lastn 

@ 

todd.retiieve  objectid,  firsm,  lasm 

@ 

(paul.in-law)  sue.retiieve  objectid,  firsm,  lasm 

@ 

andy  .retrieve  objectid,  firsm,  lasm 

@ 

samantha-ietrieve  objectid,  filrsm,  lasm 

@ 

(todd.in-law)  pauUa.retrieve  firsm,  lasm 

@ 

(samantha.business)  joe.retrieve  objectid,  firsm,  lasm  if  firsm  =  'Joe* 

@ 

(todd.in-law)  andy  .retrieve  objectid,  firsm,  lasm 
$ 


Figure  27:  Request  File  for  the  FAMILY  Database:  FAMILYoolreq 


1  george.retheve  objectid,  firstn,  lastn,  salary 

2  bertha.Tetrieve  objectid,  firstn,  lastn,  salary 

3  mike.retrieve  objectid,  firstn.  lastn 

4  paul.retrieve  objectid,  firstn,  lastn 

5  sue.retrieve  objectid,  firstn,  lastn 

6  joe.retrieve  objectid,  firstn,  lastn 

7  paulla.retrieve  objectid,  fostn,  lastn 

8  todd.retrieve  objectid,  firstn,  lastn 

9  (paul.in-law)  sue.retrieve  objectid,  firstn,  lastn 

10  andy  .retrieve  objectid,  firstn,  lastn 

1 1  sainantha.retrieve  objectid,  firstn,  lastn 

12  (todd.in-law)  paulla.retrieve  firstn,  lastn 

13  (samantha.business)  joejetrieve  objectid,  firstn,  lastn  if  flrstn  =  'Joe' 

14  (todd.in-law)  andy  .retrieve  objectid,  fostn,  lastn 

Pick  the  number  or  letter  of  the  action  desired 
(num)  -  execute  one  of  the  preceding  queries 
(d)  -  redisplay  the  file  of  queries 
(x)  -  return  to  the  previous  menu 

Action  ™  >  9 


Figure  28:  Query  Menu  After  Loading  Request  File  FAMILYodreq 
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Action  ™  >  11 

LASTN  IFIRSTN  lOBJECITD  I 

Jones  ISamantha  I0306S399  I 

Pick  the  number  or  letter  of  tfie  action  desired 
(num)  -  execute  one  of  the  preceding  queries 
(d)  -  redisplay  the  file  of  queries 
(x)  -  return  to  the  previous  menu 

Action  —  > 

10  retneve  omy  me  data  tor  me  specihea  item,  the  query  must  contam  a  condiGon 
specifying  an  attribute  value  which  is  unique.  In  our  case,  we  can  select  number  “13”  firom 
the  menu  which  retrieves  the  object  JOE  whm  the  attribute  ‘‘firstn”  equals  “Joe”.  This  will 
only  retrieve  the  data  for  the  object  JOE  as  shown  below.  If  this  condition  was  not  present, 
the  query  would  also  retrieve  the  data  for  the  object  TODD,  since  it  is  a  subclass  of  JOE. 

Action  —  >  13 

LASTN  IFIRSTN  lOBJECTID  I 

Smith  Boe  103065387  I 

Pick  the  number  or  letter  of  the  action  desired 
(num)  -  execute  one  of  the  preceding  queries 
(d)  -  redisplay  the  file  of  queries 
(x)  -  return  to  the  previous  menu 

Action  —  > 


We  can  access  data  via  a  coveting  relation  in  the  same  manner.  As  mentioned  earlier, 
a  coveting  file  is  maintained  for  each  database.  When  selecting  a  query  which  uses  a 
covering  construct,  the  system  verifies  that  the  covering  construct  used  in  the  query  exists 
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in  the  covering  file.  If  the  construct  does  exist,  the  query  proceeds,  if  the  construct  does  not 
exist,  the  query  is  refused.  If  we  select  number  **9”  from  the  query  menu  as  shown  below, 
the  system  will  refuse  the  query  because  no  covering  construct  exist  for  that  query. 


No  covering  construct  exists  for  this  query. 

Query  refused. 

Pick  the  number  or  letter  of  the  action  de^ed 
(num)  -  execute  one  of  the  preceding  queries 
(d)  >  redisplay  the  frle  of  queries 
(x)  -  return  to  the  previous  menu 

Action  ™  > 


However,  if  we  select  query  number  “14”,  it  wiU  be  successful  because  the  covering 
file  contains  the  covering  construct  found  within  die  query. 


Action  —  >  14 

LASTN  IFIRSTN 

lOBJECnD  1 

Jones  lAndy 

103065397  1 

Pick  the  number  or  letter  of  die  action  desired 
(num)  -  execute  one  of  the  preceding  queries 
(d)  -  redisplay  the  frle  of  queries 
(x)  -  return  to  the  previous  menu 

Action  —  > 

There  are  times  when  the  queries  listed  in  the  query  frle  are  insuffrcient  to  accomplish 
the  job  at  hand.  Instead  of  having  to  write  a  new  frle  in  order  to  process  a  few  queries,  the 
objea-oriented  interface  allows  the  user  to  enter  queries  at  die  tnminal  for  record 
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processing.  In  order  to  enter  queries  from  the  terminal,  the  user  must  select  ‘Y*  from  the 
database  processing  menu.  After  selecting  this  option,  the  system  will  prompt  die  user  to 
enter  the  queries  in  the  format  identical  to  die  format  for  query  file  in  Figure  27.  Each 
request  should  be  separated  by  a  character  and  the  last  request  should  be  followed  by 
a  character.  The  screen  display  for  this  procedure  is  shown  below. 


Enter  your  choice 

(d)  -  display  schema 

(c)  -  create  covering  relation  between  two  objects 

(m)  -  mass  load  from  a  data  file 

(f)  -  read  in  a  group  of  queries  from  a  file 

(t)  -  read  in  queries  from  the  terminal 

(x)  -  return  to  previous  menu 

Action  ™  >  t 


Please  enter  your  transactions  one  at  a  time. 

You  may  have  multiple  lines  per  transaction. 

Each  transaction  must  be  separated  by  a  line  that 
only  contains  the  character 

After  the  last  transaction,  the  last  line  must  consist  only 
of  the  '$'  character  to  signal  end-of-file. 

Input  the  transactions  on  the  following  lines : 

todd.retrieve  firstn,  lastn 

bertha.retrieve  firstn,  lastn,  objectid 
$ 


AfiCT  inputting  the  request,  the  system  will  generate  a  selection  request  menu.  This 
menu  is  visually  and  functionally  identical  to  the  previous  request  menu,  which  was  used 
to  load  requests  from  a  file.  Selection  of  a  request  by  number  will  perform  the  query  and 
retrieve  the  data.  The  screen  display  of  the  query  menu  and  a  sample  query  are  shown 
below. 
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1  todd.ietrieve  firstn,  lastn 

2  bertha.Tet]ieve  firstn.  lastn,  objectid 

Pick  the  number  or  letter  of  the  action  desired 
(num)  -  execute  one  of  the  preceding  queries 
(d)  -  redisplay  the  file  of  quoies 
(x)  -  return  to  the  previous  mmu 

Action  —  >2 


OBJECTID  ILASTN  IFIRSTN  I 


01565702  ISmith  (Bertha  I 

01565708  (Smith  (Sue  ( 

01565710  (Smith  Joe  ( 

01565715  (Smith  (Todd  ( 

Pick  the  number  or  letter  of  the  action  desired 
(num)  •  execute  one  of  the  preceding  quoies 
(d)  -  redisplay  the  file  of  quoies 
(x)  -  return  to  the  previous  menu 

Action  —  > 


F.  CONCLUSION 

Before  concluding  this  tutorial  it  is  important  to  note  that  the  object-oriented 
interface,  in  its  current  state  of  development,  caimot  perform  on-]i  ne  updates  or  deletes.  In 
order  to  perform  updates  or  deletes  on  the  database,  the  user  must  exit  die  system  and 
modify  the  schona  and  record  files.  However,  the  usia  must  be  cognizent  of  the  fact  that 
deletions  or  modifications  to  the  schema  may  cause  unintended  changes  to  the  inheritance 
structure.  For  instance,  when  modifying  the  schema  file,  the  user  must  avoid  deletions  or 
modifications  such  diat  objects  inheriting  from  the  modified  object  become  comipted. 
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Fmthennore,  if  an  object  containing  attributes  inherited  by  its  subclasses  is  deleted,  then 
the  same  attributes  will  also  be  deleted  from  all  of  its  associated  subclasses. 

The  object-oriented  database  does  have  an  on-line  insert  (^ability.  This  is  performed 
as  a  request  using  the  keyword  insert  instead  of  retrieve.  The  insert  procedure  can  be 
performed  at  the  terminal  or  called  from  a  text  file  in  the  same  nuuuier  as  the  retrieval 
inrocedure.  An  example  of  an  insert  request  would  be: 

<object>.insert  <attribute  1  value>  <attribute  2  value>^,,  <attribute  n  value> 

The  desired  attribute  values  for  the  record  are  entered  in  the  same  order  that  they 
appear  in  the  schema.  For  example,  assume  die  record  to  be  inserted  into  the  object 
GEORGE  contained  the  following  attribute  values:  “1“  for  objectid,  “George"  for  first 
name,  “Jones"  for  last  name,  and  “13000"  for  salary.  The  resulting  insertion  request  is 
shown  below: 


george.insert  1,  George,  Jones,  130000 

$ 

It  is  important  to  note  that  this  record  does  not  rqilace  the  existing  record,  but  rather 
is  added  to  the  current  object  GEORGE.  Consequently,  if  each  objea  in  the  database 
represents  a  single  record,  as  in  the  case  of  the  FAMILY  database,  then  any  query  on 
George  will  produce  two  results  when  only  one  is  desired. 

This  completes  the  tutorial  for  the  object-oriented  interface  on  MDBS.  To  exit  the 
system,  select  ‘V’  at  each  menu  display.  Ronember  to  stop  all  processes  and  zero  the  disk 
upon  completion  of  the  database  work.  For  additional  information  on  using  the  Object- 
Oriented  Interface  on  MDBS  refer  to  die  original  thesis  for  this  interface  [Karl93]. 


108 


LIST  OF  REFERENCES 


[Bour93] 

[Booc91] 

[Elina89] 

[Hsia91a] 

[HsiaPlb] 

[Hsia91c] 

(Hsia92a] 

[Hsia92b] 

[Hsia92c] 

[John93] 

[Karl93] 

[Meek93] 


Bourgeois,  Paul;  The  Instrumentation  of  the  MultimodeUMultiUngual  User 
Interface^  Master’s  Thesis,  Naval  Postgraduate  School,  Monterey,  California,  March 
1993. 

Booch,  G.,  Object  Oriented  Design^  The  Benjamin/Cununings  Publishing  Conq)any, 
Inc.,  1991. 

Elmarsi,  R.,  Navathe,  S.,  Fundamentals  of  Database  Systems,  The  Boijamin/ 
Cummings  Publishing  Company,  Inc.,  1989. 

Hsiao,  David  K.  and  Kamel,  M.N.,  ‘‘The  Multimodel  and  Multilingual  Approach  to 
Interoperability  of  Multidatabase  Systems,”  International  Coitference  on  Inter- 
opercdtility  of  Multidatabase  Systems,  Kyoto,  Japan,  April  1991. 

Hsiao,  David  K.,  “The  Relationship  of  Data  Models  and  Security  Requirements:  Part 
One  -  The  Object-Oriented  Data  Model  and  the  Need-to-Know  Policy,”  sulnnitted  to 
Fifth  IFIP  WG  II 3  Working  Corference  on  Database  Security,  West  Virginia, 
November  4-7, 1991. 

Hsiao,  David  K.,  “The  Relationship  of  Data  Models  and  Security  Requirements:  Part 
IWo  -  The  Object-oriented  Data  Model  and  the  Multilevel  Security  Policy,” 
November  1991. 

Hsiao,  David  K.,  “Federated  Databases  and  Systems  -  Part  I:  A  Thtorial  on  their 
Data  Sharing,”  VLDB  Journal,  1, 1992,  pp.  127-179. 

Hsiao,  David  K.,  “Federated  Databases  and  Systems:  Part  11-  A  Thtorial  on  their 
Resource  Consolidation,”  VLDB  Journal,  2, 1992,  pp.  285-310. 

Hsiao,  David  K.,  “The  Object-Oriented  Database  Management  -  A  Tutorial  on  its 
Fundamentals,”  Proceedings  of  the  Second  Far-East  Workshop  on  Future  Database 
Systems,  Kyoto,  Japan,  April  1992.,  pp.  398-416. 

Johnston,  Richard,  The  Relational-to-Object-Oriented  Cross-Model  Accessing 
Capability  in  a  Multimodel  and  Multilingual  Database  System,  Master’s  Thesis, 
Naval  Postgraduate,  Monterey,  California,  March  1993. 

Karlider  Tuigay  and  Moore,  John  W.,  Design  and  Implementation  of  an  Object- 
Oriented  Interface  for  the  Multi-ModeUMulti-Ungual  Database  System,  Ma^’s 
Thesis,  Naval  Postgraduate  School,  M^h  1993. 

Meeks,  Andrew  P.,  The  Instrumentation  of  the  Multibackend  Database  System, 
Master’s  Thesis,  Naval  Postgraduate  School,  June  1993,  pp.  10-15. 


109 


[Roll84]  Rollins,  R.,  Design  and  Analysis  of  a  Complete  Relational  Interface  for  a  Multi- 
Backend  Database  System,  Master’s  Thesis,  Naval  Postgraduate,  School,  Monterey, 
California,  June  1984. 


no 


INITIAL  DISTRIBimON  LIST 


1.  Defense  Technical  Infonnation  Center  . 2 

Cameron  Station 

Alexandria,  VA  22304-6145 

2.  Dudley  Knox  Library . 2 

Code  52 

Naval  Postgraduate  School 
Monterey,  CA  93943-5002 

3.  Chairman,  Code  CS  . 2 

Computer  Science  Department 

Naval  Postgraduate  School 
Monterey,  CA  93943 

4.  Lieutenant  Todd  G.  Estes,  USN  . 1 

66  Bliss  Road 

Newport,  RI  02840 

5.  Captain  Donald  H.  Estes,  USN  . 1 

Military  Chair  of  Intelligence 

Naval  War  College 
Newport,  RI  02841 

6.  Professor  David  K.  Hsiao  . 2 

Computer  Science  Department 

Naval  Postgraduate  School 
Monterey,  CA  93943 

7.  Ms.  Doris  Mlezko  . 2 

CodeP22305 

NAWCWPNS 

Point  Mugu,  CA  93042-5001 

8.  lieutenant  Eric  M.  Mueller,  USN  _ _ ; . 1 

2823  Kelsey  Street 

Berkeley,  CA  94705 

9.  Ronald  J.  Roland . 1 

500  Sloat  Avenue 

Monterey,  CA  93940 


111 


